Encryption and Secure Remote Access | Linux Hardening TryHackMe

We explored encryption and secure remote access as methods to secure and harden Linux. Encryption makes data unreadable without the decryption key. In the scenario where an adversary has complete physical access to your laptop, for instance, by stealing it, we want to ensure that it won’t be of any use to them. A disk drive full of encrypted data should be as good as a damaged one. When you set up your Linux system with SSH for remote administration, you also make your Linux box available for all interested parties. Many malicious hackers search the Internet for listening SSH servers and start to guess the login credentials; usually, they try root with the most common passwords.. This was part of TryHackMe Linux System Hardening

Get Blue Team Notes

Encryption

Encryption makes data unreadable without the decryption key. In the scenario where an adversary has complete physical access to your laptop, for instance, by stealing it, we want to ensure that it won’t be of any use to them. A disk drive full of encrypted data should be as good as a damaged one.

There are various software systems and tools that provide encryption to Linux systems. Since many modern Linux distributions ship with LUKS (Linux Unified Key Setup), let’s cover it in more detail.

We have the following fields:

• LUKS phdr: It stands for LUKS Partition Header. LUKS phdr stores information about the UUID (Universally Unique Identifier), the used cipher, the cipher mode, the key length, and the checksum of the master key.
• KM: KM stands for Key Material, where we have KM1, KM2, …, KM8. Each key material section is associated with a key slot, which can be indicated as active in the LUKS phdr. When the key slot is active, the associated key material section contains a copy of the master key encrypted with a user’s password. In other words, we might have the master key encrypted with the first user’s password and saved in KM1, encrypted with the second user’s password and saved in KM2, and so on.
• Bulk Data: This refers to the data encrypted by the master key. The master key is saved and encrypted by the user’s password in a key material section.

LUKS reuses existing block encryption implementations. The pseudocode to encrypt data uses the following syntax:

enc_data = encrypt(cipher_name, cipher_mode, key, original, original_length)

As we can see, LUKS works with different ciphers and cipher modes. Original refers to the plaintext data of length, original_length. The user-supplied password is used to derive the encryption key; the key is derived using password-based key derive function 2 (PBKDF2).

key = PBKDF2(password, salt, iteration_count, derived_key_length)

Using a salt with a hash function repeating an iteration count ensures that the resulting key is secure enough for encryption. For more information, you might want to refer to the Introduction to Cryptography room.

Similarly, to decrypt data and restore the original plaintext, LUKS uses the following syntax:

original = decrypt(cipher_name, cipher_mode, key, enc_data, original_length)

Most distributions let you encrypt a drive using a graphical interface. However, if you would like to set up LUKS from the command line, the steps are along these lines:

• Install cryptsetup-luks. (You can issue apt install cryptsetup, yum install cryptsetup-luks or dnf install cryptsetup-luks for Ubuntu/Debian, RHEL/Cent OS, and Fedora, respectively.)
• Confirm the partition name using fdisk -l, lsblk or blkid. (Create a partition using fdisk if necessary.)
• Set up the partition for LUKS encryption: cryptsetup -y -v luksFormat /dev/sdb1. (Replace /dev/sdb1 with the partition name you want to encrypt.)
• Create a mapping to access the partition: cryptsetup luksOpen /dev/sdb1 EDCdrive.
• Confirm mapping details: ls -l /dev/mapper/EDCdrive and cryptsetup -v status EDCdrive.
• Overwrite existing data with zero: dd if=/dev/zero of=/dev/mapper/EDCdrive.
• Format the partition: mkfs.ext4 /dev/mapper/EDCdrive -L "Strategos USB".
• Mount it and start using it like a usual partition: mount /dev/mapper/EDCdrive /media/secure-USB.

If you want to check the LUKS setting, you can issue the command cryptsetup luksDump /dev/sdb1. In the terminal output below, we can see the UUID of the encrypted disk. We can also see that the cipher used is aes-xts-plain64. As for the key, PBKDF2 used SHA256 with the provided salt for 194180 iterations.

Secure Remote Access

Providing remote access to a system is a very convenient way to access your system and files when you are not physically present at the target system’s keyboard. However, this also means that you are voluntarily providing a service that attackers will target. Common attacks include:

1. Password sniffing
2. Password guessing and brute-forcing
3. Exploiting the listening service

Protecting Against Password Sniffing

Remote access can be achieved through many different protocols and services. Although all modern systems use encrypted protocols, such as the SSH protocol, for remote access, older systems might still use cleartext protocols, such as the Telnet protocol.

In the following figure, although the user has selected a strong password, it is being sent in cleartext, which is readable to anyone with a packet-capturing tool across the network path.

It is crucial to ensure that you select a protocol that encrypts traffic. The SSH protocol has been around for more than two decades. It has stood the test of time. It has many uses ranging from secure remote access to secure file transfers.

Protecting Against Password Guessing

When you set up your Linux system with SSH for remote administration, you also make your Linux box available for all interested parties. Many malicious hackers search the Internet for listening SSH servers and start to guess the login credentials; usually, they try root with the most common passwords.

The figure below shows that the system uses the SSH protocol to ensure encrypted communications; however, authentication relies on login credentials. Many users are tempted to use weak passwords or reuse the same password with other services. Although qwerty1234 is not in an English dictionary, it is commonly found among the top 10 or 20 most common passwords, making it easy to guess.

Because your SSH server will be configured to listen for incoming connections 24 hours a day, 365 days a year, evil users have all the time in the world to attempt one password after another. There are a few guidelines that you can use:

1. Disable remote login as root; force login as non-root users.
2. Disable password authentication; force public key authentication instead.

The reasoning behind the above guidelines is that you don’t want the adversary to be able to attack the root account directly. Moreover, even if it is a non-root account, you don’t want the attacker to gain access if there is a weakness in the password.

The configuration of the OpenSSH server can be controlled via the sshd_config file, usually located at /etc/ssh/sshd_config. You can disable the root login by adding the following line:

PermitRootLogin no

Although a password such as 9bNfX2gmDZ4o is difficult to guess, most users find memorising it inconvenient. Imagine if the account belongs to the sudoers (sudo group), and the user needs to type this password every time they need to issue a command with sudo. You may have to discipline to do that, but you cannot expect this to work for everyone.

Many users are tempted to select a user-friendly password or share the same password across multiple accounts. Either approach would make the password easier for the attacker to guess.

It would be best to rely on public key authentication with SSH to help improve the security of the remote login system and make it as fail-proof as possible.

If you haven’t created an SSH key pair, you must issue the command ssh-keygen -t rsa. It will generate a private key saved in id_rsa and a public key saved in id_rsa.pub.

For the SSH server to authenticate you using your public key instead of your passwords, your public key needs to be copied to the target SSH server. An easy way to do it would be by issuing the command ssh-copy-id username@server where username is your username, and server is the hostname or IP address of the SSH server.

It is best to ensure you have access to the physical terminal before you disable password authentication to avoid locking yourself out. You might need to ensure having the following two lines in your sshd_config file.

• PubkeyAuthentication yes to enable public key authentication
• PasswordAuthentication no to disable password authentication

Room Answers

Video Walkthrough