Linux

• • Linux systems provide a reliable and robust alternative to closed-source systems, such as MS Windows Server and UNIX. Moreover, choosing Linux can help cut down licensing costs dramatically. If you are not convinced, compare the cost of hosting a web server using Debian 11 with the cost of hosting a web server using MS Windows Server 2022. When we compare the combined costs of licensing and the minimum required hardware for each of these modern releases, we will have a strong case for Linux.
• Let’s say you have taken the necessary measures to prevent intruders from taking the disk drive or the whole computer system. Moreover, you have ensured that your system passwords are complex and impossible to guess. If an intruder can access the system physically, it is a non-sophisticated task to use GRUB, a popular Linux bootloader, to reset the root password account. Hence we have the adage “boot access = root access”.
• • It is evident that we need to ensure physical security for our computer systems; however, in the unlikely event that physical security is breached, we need to provide additional layers of protection. Many BIOS and UEFI firmware allows you to add a boot password. This password will prevent unauthorised users from booting the system. However, this can only be used for personal systems; it won’t make sense to use it on servers as this will require someone to be physically present to supply the boot password.
• Linux Hardening:

  • We can consider adding a GRUB password depending on the Linux system we want to protect. Many tools help achieve that. One tool is grub2-mkpasswd-pbkdf2, which prompts you to input your password twice and generates a hash for you. The resulting hash should be added to the appropriate configuration file depending on the Linux distribution. This configuration would prevent unauthorised users from resetting your root password. It will require the user to supply a password to access advanced boot configurations via GRUB, including logging in with root access.
• • GRUB stands for Grand Unified Bootloader. It is available from the GNU project and is a common bootloader shipped with many Linux distributions.
• • PBKDF2:In cryptography, PBKDF1 and PBKDF2 are key derivation functions with a sliding computational cost, used to reduce vulnerability to brute-force attacks. PBKDF2 is part of RSA Laboratories' Public-Key Cryptography Standards series, specifically PKCS #5 v2.0, also published as Internet Engineering Task Force's RFC 2898.
• PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function, such as hash-based message authentication code (HMAC), to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations.
• 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)
• Linux Hardening:

  • 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.
• Linux Hardening:

  • 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.
• Linux HArdening

  • 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.
  • 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)
• • Example to SSH: "ssh tryhackme@10.10.217.162"
• Let’s briefly revisit the client/server model before we start. Any networked device can be a client, a server, or both simultaneously. The server offers a service, and the client connects to the server to use it. Examples of servers include web servers (HTTP and HTTPS), mail servers (SMTP(S), POP3(S), and IMAP(S)), name servers (DNS), and SSH servers. A server listens on a known TCP or UDP port number awaiting incoming client connection requests. The client initiates the connection request to the listening server, and the server responds to it
• A firewall decides which packets can enter a system and which packets can leave a system. Without a firewall, a client can communicate with any server without restrictions; moreover, a client can function as a server and listen for incoming connections from other clients. In other words, if an attacker manages to exploit a vulnerability on a system without a firewall in place, the attacker could use the exploit to listen on a chosen port number on the victim’s machine and connect to it without any restrictions.
• Setting up a firewall offers many security benefits. First and foremost, firewall rules provide fine control over which packets can leave your system and which packets can enter your system. Consequently, firewall rules help mitigate various security risks by controlling network traffic between devices. More importantly, firewall rules can be devised to ensure that no client can act as a server. In other words, an attacker cannot start a reachable listening port on a target machine; the exploit can start a listening port, but the firewall will prevent all incoming connection attempts.
• A host-based firewall is a piece of software installed on a system we want to protect. Unlike a network-based firewall, the host-based firewall restricts network packets to and from a single host. The firewall has two main functions:

  • What can enter? Allow or deny packets from entering a system.
  • What can leave? Allow or deny packets from leaving a system.
• Linux Firewalls

  • A stateless firewall can inspect certain fields in the IP and TCP/UDP headers to decide upon a packet but does not maintain information about ongoing TCP connections. As a result, a packet can manipulate a few TCP flags to appear as if it is part of an ongoing connection and evade certain restrictions. Current Linux firewalls are stateful firewalls; they keep track of ongoing connections and restrict packets based on specific fields in the IP and TCP/UDP headers and based on whether the packet is part of an ongoing connection.
• Linux FirewallsThe IP header fields that find their way into the firewall rules are:

  1. Source IP address
  2. Destination IP address

  The TCP/UDP header fields that are of primary concern for firewall rules are:

  1. Source TCP/UDP port
  2. Destination TCP/UDP port
• Linux Firewalls:

  • It is worth noting that it is impossible to allow and deny packets based on the process but instead on the port number. If you want the web browser to access the web, you must allow the respective ports, such as ports 80 and 443. This limitation differs from MS Windows’ built-in firewall, which can restrict and allow traffic per application.
• • On a Linux system, a solution such as SELinux or AppArmor can be used for more granular control over processes and their network access. For example, we can allow only the /usr/bin/apache2 binary to use ports 80 and 443 while preventing any other binary from doing so on the underlying system. Both tools enforce access control policies based on the specific process or binary, providing a more comprehensive way to secure a Linux system.
• Netfilter

  • At the very core, we have netfilter. The netfilter project provides packet-filtering software for the Linux kernel 2.4.x and later versions. The netfilter hooks require a front-end such as iptables or nftables to manage.
  • In the following examples, we use different front-ends to netfilter in order to allow incoming SSH connections to the SSH server on our Linux system. As shown in the figure below, we want our SSH server to be accessible to anyone on the Internet with an SSH client.

  
• iptables

  As a front-end, iptables provides the user-space command line tools to configure the packet filtering rule set using the netfilter hooks. For filtering the traffic, iptables has the following default chains:

  • Input: This chain applies to the packets incoming to the firewall.
  • Output: This chain applies to the packets outgoing from the firewall.
  • Forward This chain applies to the packets routed through the system.
• iptablesLet’s say that we want to be able to access the SSH server on our system remotely. For the SSH server to be able to communicate with the world, we need two things:

  1. Accept incoming packets to TCP port 22.
  2. Accept outgoing packets from TCP port 22.
• Allowing SSH with IPTables:

  Let’s translate the above two requirements into iptables commands:

  iptables -A INPUT -p tcp --dport 22 -j ACCEPT

  • -A INPUT appends to the INPUT chain, i.e., packets destined for the system.
  • -p tcp --dport 22 applies to TCP protocol with destination port 22.
  • -j ACCEPT specifies (jump to) target rule ACCEPT.
• Allowing SSH with IPTables:

  iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

  • -A OUTPUT append to the OUTPUT chain, i.e., packets leaving the system.
  • -p tcp --sport 22 applies to TCP protocol with source port 22.
• Allowing SSH with IPTables:

  Let’s say you only want to allow traffic to the local SSH server and block everything else. In this case, you need to add two more rules to set the default behaviour of your firewall:

  • iptables -A INPUT -j DROP to block all incoming traffic not allowed in previous rules.
  • iptables -A OUTPUT -j DROP to block all outgoing traffic not allowed in previous rules.
• Allow only to local ssh server and drop everything else:

  
• nftables

  • nftables is supported in Kernel 3.13 and later, adding various improvements over iptables, particularly in scalability and performance.
• Unlike iptables, nftables start with no tables or chains. We need to add the necessary tables and chains before adding rules. To begin, we will create a table, fwfilter.

  nft add table fwfilter

  • add is used to add a table. Other commands include delete to delete a table, list to list the chains and rules in a table, and flush to clear all chains and rules from a table.
  • table TABLE_NAME is used to specify the name of the table we want to create or work on.
• nftables:

  In our newly created table, fwfilter, we will add an input chain and an output chain for incoming and outgoing packets, respectively.

  • nft add chain fwfilter fwinput { type filter hook input priority 0 \; }
  • nft add chain fwfilter fwoutput { type filter hook output priority 0 \; }

  The above two commands add two chains to the table fwfilter:

  • fwinput is the input chain. It is of type filter and applies to the input hook.
  • fwoutput is the output chain. It is of type filter and applies to the output hook.
• nftables:

  With the two chains created within our table, we can add the necessary rule to allow SSH traffic. The following two rules are added to the table fwfilter to the chains fwinput and fwoutput, respectively:

  • nft add fwfilter fwinput tcp dport 22 accept accepts TCP traffic to the local system’s destination port 22.
  • nft add fwfilter fwoutput tcp sport 22 accept accepts TCP traffic from the local system’s source port 22.

  We can check the shape of the fwfilter table using the command nft list table fwfilter:
• UFWUFW stands for uncomplicated firewall. Let’s see how it stands for its promise of being uncomplicated. We will allow SSH traffic. This firewall rule can be achieved through one of the following commands:

  • ufw allow 22/tcp

  It configures the firewall to allow traffic to TCP port 22. We can confirm our settings with the command ufw status

  
• Firewall Policy

  Before configuring a firewall, you need to decide upon the firewall policy. You might be the decision maker regarding the firewall policy or an enforcer of an existing security policy that covers firewall configuration. It all depends on the system you are protecting.

  We will not go into security policies as this is outside the scope of this room. We will mention that the two main approaches are:

  • Block everything and allow certain exceptions.
  • Allow everything and block certain exceptions.
• 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

  
• 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.
  • 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.
• There are a few guidelines that you can use for securing SSH servers:

  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.