How to protect your IT infrastructure: 8 basic tips

Started by metallexportprom, Aug 11, 2022, 01:25 AM

Previous topic - Next topic

metallexportpromTopic starter

Increasingly, there is info about data breaches in the news, and large companies spend fabulous sums on strengthening safety. According to the consulting organization IDC, by 2021, global spending on IT Security will exceed $120 billion.

However, building a secure IT infrastructure doesn't have to cost a lot of money. For instance, the Linux system has built-in protection mechanisms that, when properly configured, can reflect the most popular kinds of attacks on the OS and networks.



In this article, we will look at a few basic tips that reduce the likelihood of hаcking an IT architecture and compromising information. The examples in the post are given for Linux-based systems, however, some of the practices described are applicable to other operating systems.



Install the latest security updates

This point is quite obvious, and the importance of regular application updates has been written before, however, sadly, it even so does not lose its relevance. Just look at the situation with the vulnerability in OpenSSL - Heartbleed (CVE-2014-0160).

It allows attackers to extract the server's private key and use it to decrypt transmitted traffic. At the time of publication of information about the error in 2014, the number of vulnerable sites totaled 600 thousand. At the same time, Google developers Bodo Möller and Adam Langley prepared a patch that fixed the vulnerability. However, not everyone has installed the update, and according to Shodan, nearly 250,000 websites are even so affected by Heartbleed.

To keep systems up to date, we suggest that you set up safety auto-update for your OS. Most vendors offer a tool to automatically install patches. For instance, Debian has Unattended Upgrades, and Red Hat-based systems have Auto-Updates. On CentOS, yum-cron is available, and on Fedora, dnf-automatic is available.

You can also upgrade using package managers. For instance, for Debian:

apt-get update && apt-get upgrade


Automatic installation of patches has its drawbacks, for instance, there are situations when updates lead to a system crash. Therefore, before installing updates in a production environment, it is worthwhile to conduct preliminary software testing in a sandbox.

Service pack developers try to ensure that software products do not make potentially harmful changes to the system, but they cannot test every possible combination of applications and services. For instance, the recently released KB4041676 patch for Windows 10 sent some users' computers into an endless reboot loop and produced a blue screen of death.

At the same time, some systems after the upgrade even so remain vulnerable to exploits until all the processes associated with them are rebooted. For instance, in 2014, several vulnerabilities were discovered in OpenSSL that allow attackers to carry out DDoS attacks. They were closed in Debian 1.0.1e-2+deb7u10, but required a restart of all OpenSSL-related applications for them to take effect. The community has developed the check restart and needs-restarting utilities to find programs that need a restart.


Activate security extensions

Modern systems run dozens of daemons and programs owned by different users. The traditional Unix model (DAC - Discretionary Access Control), called voluntary, works with three parameters when assigning access rights: user, user group, and others, which complicates the application management procedure.

To give administrators more options for setting up security policies, safety extensions have been developed based on the MAC (Mandatory Access Control) model, that is, forced access control. They complement the classic model and make it possible to set security policies for all processes. For instance, "order" the web server to listen on a given port, or allow it to read files only from a specified directory.

Security applications include SELinux, AppArmor, and GrSecurity (there are others), each with its own strengths and weaknesses. Next, we'll take a quick look at SELinux because it's the most secure (it was designed for government use) and, as sysadmin and nixCraft creator Vivek Gite points out, has the most powerful access control mechanisms.

It has three modes of operation. Enforcing is the default mode, which blocks actions that violate established safety policies. The second mode (Permissive) captures all violations in the log, but does not block them. The third state - Disabled - means that the system is disabled.

You can find out which mode is set by typing the following command:

$ /usr/sbin/getenforce


To enable SELinux, enter (for Fedora):

rpm-qa | grep selinux
rpm -q policycoreutils
rpm-qa | grep setroubleshoot # check installed packages


The utility provides several access control models:

    Type Enforcement (TE): The primary access control mechanism. Flexible but labor intensive. All objects and subjects are tagged with identifiers, which can then be used to assign rules and policies.
    Role-Based Access Control (RBAC): Systems are defined with roles associated with one or more domain kinds. A diagram with them can be found here.
    Multi-Level Security (MLS): All objects in the system receive a certain level of access that limits their capabilities. At their level, services can read and write information, at levels above they can only write, and below they can only read. A diagram with safety levels is available at the link.


An example of a situation in which SELinux will protect the infrastructure is a configuration error. DNS servers often perform what is known as a zone transfer, when they replicate data among themselves. Attackers can use this procedure to broadcast false information to servers. When running BIND on Fedora, even if the administrator forgets to restrict which servers are allowed to share information, SELinux policy will prevent zone files from being modified during replication.

SELinux also allows you to block access for processes to files used by other processes. For instance, an attacker will not be able to compromise a Samba server and then modify files on other systems, say, a MySQL database, through it.


Set up access rights and set password policies

This point is also quite obvious, but it does not cease to be relevant. According to a study conducted by Intermedia in 2015 among two thousand office workers, 93% of respondents admitted that they neglected the requirements of information security at least once. At the same time, 67% of IT industry workers answered that they share logins and passwords from various accounts with colleagues.

Weak and generic passwords increase the likelihood of "infection" of the company's architecture, and improperly configured access rights open loopholes to the organization's systems. Therefore, we do not suggest connecting to the server as an administrator (root). It is better to create a new user, limit his rights and work through this account, and perform administration using sudo.

As Stack Exchange residents note, this approach makes life difficult for attackers. hаckers can use bots that send an SSH connection request (ssh root@$IP) and then guess a password using standard combinations ("root" or "password1234" are some of the most popular) or brute force. If they manage to gain root access, then they acquire "unlimited power" over the system.

But if root can't connect via SSH, the bots will have to guess the username first, making it harder to hаck.

To create a new user on Debian and Ubuntu, enter the following command into the console:

adduser administrator


The administrator field can be changed to anything. Next, a password is entered. Password Depot recommends making passwords 8-10 characters long with mixed case letters, numbers, and special characters. Jeff Atwood, author of the Coding Horror weblog and co-founder of the Stack Overflow and Stack Exchange platforms, notes that a password of 10 or more characters reduces the likelihood of it appearing in the most popular list by 80%.

Yes, the need to compose complex and long passwords is well known, but in practice, not everyone follows this rule. The SplashData team analyzed more than 5 million passwords from corporate employee accounts leaked in 2016. The researchers concluded that most of the passwords were completely insecure. The password "123456" became the most popular and was used by 5% of the accounts of the entire "test" set. Approximately the same percentage scored the password "password".

It is also worth taking care of the data for authorization of other users of the north. Weak passwords can be detected using the John the ripper utility. To make sure that there are no "passwordless" users in the system, the command will help:

awk -F: '($2 == "") {print}' /etc/shadow


To make password creation a mandatory procedure and set the "expiration time" of the password, change the settings in the pam_crаcklib.so file:

chage -M 60 -m 7 -W 7 UserName


Prevent the reuse of old passwords in pam_unix.so and set a limit on the number of login attempts.

If you have several applications, each of which can access different critical info, it is worth running them from separate accounts and blocking access of one application to the data of another.

According to Mailgun, a company that develops APIs for embedding mail services in applications, the goal of this approach is to reduce the number of "options" for a hаcker if he does manage to break into the system. When the application's list of actions is limited to the required minimum, an attacker will not be able, for instance, to elevate access rights and cause serious damage.

"Demonize" the service so that it immediately starts under the desired user. There are two ways to do this. The first is using OS scripts (init or systemd) to start / stop the application and a monitoring tool (monit) to restart it in case of a crash. The second approach is to use a process control system (supervisord, s6, daemontools), which will manage the application on its own.


Set firewall rules and exceptions

Recently, a vulnerability (CVE-2017-15908) was discovered in the systemd manager that allows DDoS attacks. When the affected system sent a DNS query to the hаcker-controlled DNS server, it returned a special query that put systemd into an endless loop causing 100% CPU usage.

One way to protect against this type of attack is to configure the firewall - in this case, the firewall is instructed to block potentially malicious packets that contain the resource records described in section 4 of RFC 4034.

In general, by opening only a small number of services to outside access, you reduce the number of "points of contact" and, as a result, reduce the likelihood of penetration into your system.

When setting firewall rules, the Mailgun team recommends following these principles:

    Before setting up new rules, delete existing ones.
    By default, set the DROP option to handle incoming traffic (any traffic that does not meet the established rules will not be allowed through). After that, you can gradually begin to "open up" access to the external network.
    Do not completely restrict Internet Control Message Protocol (ICMP) traffic. Routers and hosts use it to transmit critical information about service availability, packet sizes, and more. As noted on Stack Exchange, it is probable to restrict ICMP, but the format of these bans will depend on the company's architecture.
    If you are not using IPv6, limit this traffic.


Establish a secure connection via SSH

First, generate a strong SSH key. This can be done with ssh-keygеn:

ssh-keygеn -t rsa -b 4096 -C foo@example.com


After that, you need to enter a passphrase that will protect the key in case it is compromised. To organize an SSH connection, you can use OpenSSH, which has a decent standard configuration. You can find detailed information about OpenSSH options in the Mozilla manual or on the CentOS wiki page.

For our part, we suggest using cryptographic key pair login for SSH access. The second key makes brute-force crаcking much more difficult. As noted above, the longer the password, the more secure it is, and the SSH key can be, for instance, 2048 bits long.

To do this, you need to create new keys and upload the public key to the server. From the local computer, enter:

ssh-copy-id admin@1.1.1.1


Replace admin with the key owner's name and 1.1.1.1 with your server's IP address. You need to reconnect to test the connection.

You can also completely disable the SSH connection by entering a password, so that everyone uses the keys. Then the value of the PasswordAuthentication parameter in the /etc/ssh/sshd_config file should be set to no.

On Ubuntu (or Debian) it would look like this:

nano /etc/ssh/sshd_config

...
PasswordAuthentication no


Note that additional connection safety can be provided using 2FA.


Use cryptography

Protecting infrastructure from intruders involves the use of cryptography. Do not store personal and account information unencrypted. Even if your passwords are in a private repository on GitHub. This way you will protect your architecture in case GitHub is compromised, which already happened the year before last. The attacker, using a list of passwords and email addresses compiled as a result of hаcking other services, compromised several user accounts and gained access to corporate information.

When choosing an encryption tool or library, the Mailgun team, as well as Stack Exchange residents, are advised to follow these rules:

    Use modern symmetric ciphers: AES and Salsa20 (NaCl) are the most popular options.
    Use MAC (message authentication code) to control the integrity and authentication of the data source. Good options would be HMAC-SHA-512 or Poly1305.
    Pay attention to high-quality randomizers for generating keys and temporary codes. For instance /dev/urandom.
    If the tool works with passphrases, make sure it uses KDF.


On Stack Exchange in the corresponding thread, users cite many tools for creating encryption systems (for instance, entlib or Bouncy Castle). If you really need to, you can create your own utility, but residents of Reddit and Quora say that this approach only increases the risk of hаcking. As noted on Stack Exchange, most often, homemade ciphers rarely survive attacks by hаcker tools to break polyalphabetic ciphers and substitution ciphers.

In addition, we give several sources that you can familiarize yourself with before starting work with cryptographic systems. The first is the Crypto101 course, taught by Laurens Van Houtven, director of Principal, which trains startup security teams. The second resource, the matasano crypto challenges, contains 48 exercises demonstrating attacks on real ciphers. The authors claim that this is a more efficient way to learn cryptographic principles than reading books on the topic.


Create and check backups regularly

The issue with backups is a bit out of the general theme of the above topics, it is also important for ensuring the safety of the architecture. Again, this topic is "chewed" in many materials, but we consider it necessary to repeat ourselves, since even large companies make mistakes in these matters.

Recent examples include the removal of a part of the database with requests to change the documentation and code of GitLab user projects by a system administrator from the Netherlands. Then the company noted that none of the five implemented backup storage systems helped restore information.

Therefore, it is worth creating backups and checking their readiness as often as possible, of course, taking into account business requirements. For instance, engineers at Neon Rain, a web application developer, back up files once a week and back up databases every night. Databases are backed up daily to Cloud Academies. As for checking backups, for instance, in the Chalvington Group, the possibility of recovery is assessed every morning.

In general, creating a backup copy once a day is a normal practice. The main thing is to restrict access to servers with backups, and for accounts that will even so access them, it is worth using authorization mechanisms that are different from those used by the main architecture.

If you do not want to organize your own backup infrastructure, then it makes sense to transfer this task to a third-party vendor who will take care of storing backups. For instance, in 1cloud we perform backups once a day, and the client himself chooses the required time for storing copies (7, 14, 21 or 28 days).

The tools and settings listed above will help you secure your system. Yes, it is physically not possible to protect IT architecture 100% from all kinds of attacks, but it is probable to complicate the lives of hаckers and limit the number of potential exploits. By being diligent, attentive and accurate, you can buy the time you need to make key decisions and implement defensive countermeasures.
  •  
    The following users thanked this post: Sevad

Kitty Solam

Let's say patches from Meltdown, what promise a drop in performance and lead to a crash on some systems. I'm already seeing a failure to install them.
Therefore, I would rephrase - organize a system of preliminary testing of updates with their subsequent deployment. And also coordinate
 your protection system in such a way as to minimize the risk of exploiting unknown vulnerabilities.
  •