Skip to content

Implementing FEA407 - Control Access to the Server
Document Implementing FEA407 - Control Access to the Server
Author: Noora Kuikka
Version: 1.0
Date: 11.03.2024

Description

This feature implements role-based access control (RBAC) to the frontend and backend servers running the Tukko application. Access control is a fundamental security concept that regulates who or what can view or use resources in a computing environment. By ensuring that only authorized users have access to the development environment and the files contained therein, we can help prevent security breaches or accidental modifications to critical files.

In this section we will detail the methods we used to set up access control measures on both the frontend and backend servers, as well as the reasoning behind the steps we took.

Preparation

The first thing we did was separate the frontend and backend servers into their own subnet. Only the frontend is directly accessible through the external internet via a NAT-enabled virtual router. This subnet is protected by the cPouta firewall, which has been configured to only allow in the traffic necessary for the functionality of the Tukko service and its development.

SSH into frontend

In order to access the backend, authorized users must first SSH into the frontend, and from there they can SSH into the backend server. Each server will be additionally protected by a web application firewall (OWASP ModSecurity) to ensure that there are several layers of security protecting the servers from unauthorized traffic. See FEA409 for more details on the firewall implementation.

SSH into backend

Both servers have also been updated with the latest packages and security patches.

Access Requirements

This section defines the access requirements to the Tukko servers.

Users: The users of the application should only require direct HTTP or HTTPS access to the frontend server. The frontend will communicate with the backend to serve the data that they request.

Developers: The project development team will require SSH access to both the frontend and backend. Additionally they require access to the project directories and files, with the ability to make modifications and changes within those directories.

Administrators: The administrators are the only users who should have full access to both servers - with the ability to make system configurations, create or remove accounts, delete directories etc.

Implementation

Step 1: User Accounts and Authentication

Individual user accounts were created for each user requiring access to the servers.

Creating users

These accounts are protected via strong password policies following the National Institute of Standards and Technology (NIST) best practise guidelines. Each password and associated username is stored securely in a password manager (Bitwarden) accessible only by the administrators of the project. This password manager has been setup to utilize multifactor authentication (MFA), and will be used to both share and create passwords within the organisation in a secure manner.

Each user is additonally separated into groups based on their access requirements. Only the administrators belong to the sudoers group. The other users will be assigned access to groups based on the principle of least privilege. In practise this means that the development team will only be able to modify the files contained in the project directories, without the ability to make configuration changes to the server itself.

Creating groups Additionally system wide permissions have been checked and modified to ensure that they match the recommended security standards established by NIST baselines.

As an example, in the below image we have created a project directory for the Tukko frontend, and assigned the developer group read, write and execute permissions for all files within that directory. Users outside the developer group will have no access to the directory contents.

Creating project directory

Directory permissions

Step 2: Securing SSH

In order to secure SSH access to the servers, we were required to edit the sshd_config file. Before this, we took a backup of the original config to ensure that we could easily revert to the previous configuration in case of errors.

The following changes were made to the sshd_config file:

PermitEmptyPasswords no

Do not permit empty passwords

This setting ensures that users will always require a password to login, preventing attackers from gaining persistent access to the system by creating user accounts with empty passwords. Administration errors could also result in the future creation of accounts containing empty passwords. While we have ensured that all accounts are password protected, this configuration will reduce the overall attack surface.

PermitRootLogin no

Do not permit root login

This setting will prevent anyone from attempting to login to the server using a root account. Users must instead login with standard user accounts, then if necessary, elevate their privileges once they have gained access. As root accounts have complete control over the system, allowing root login would be a serious security risk.

AllowUsers usernames

Whitelist SSH users

This setting specifies which users have SSH access to the server by whitelisting only the usernames included in the configuration file. It allows fine-tuned control over who can access the server via SSH, and can be modified when necessary to add or delete users.

ClientAliveInterval 7200

ClientAliveCountMax 3

Client alive interval

Both of these settings control when connections to the server are automatically timed out. In this case an idle connection will only be kept alive for 2 hours, after which the server sends a message to the client expecting a response. If there is no response after three messages, the connection is dropped. This ensures that users cannot stay connected to the server indefinitely.

PublicKeyAuthentication yes

Allow public key authentication

While in our development team, we have implemented password authentication for ease of use, for truly secure access to the server only public and private keys should be used. This ensures that an attacker cannot brute-force a password to login to the server, and will always require a copy of the private key in order to gain access.

Step 3: Implement Fail2Ban

Fail2Ban is an open-source project for a daemon that scans log files and automatically bans IP addresses that conduct too many failed login attempts. This will significantly mitigate the risk of brute-force attacks.

Fail2Ban is easy to set-up, as most Linux distributions already contain packages that can be installed with a simple commad:

sudo apt install fail2ban

After installation, we can enable fail2ban to start at system boot with:

sudo systemctl enable fail2ban

Or manually with:

sudo systemctl start fail2ban

And the status of fail2ban can be checked with the command:

sudo systemctl status fail2ban

Fail2Ban system start configuration

Additionally the configuration files can be customized from the /etc/fail2ban/ directory.

In the below image we have added a custom configuration for ssh logins:

Fail2Ban SSH config

These settings have set the maximum authentication attempts to 3, before a ban of 3 hours is activated.

Step 4: Enable Audit Logging

In order to enable audit logging with fine-tuned control over auditing rules, we first installed auditd using:

sudo apt install auditd

We then started the service with:

sudo systemctl start auditd

And enabled it to start on boot:

sudo systemctl enable auditd

The logs can now be searched using sudo ausearch -m [parameters]. Below is an example of searching for failed login attempts (none were found):

Enable audit controls

And here can be seen some failed login attempts on the backend server:

Audit failed logins

Sources

Sources
Lynis
CIS Linux Hardening Benchmark
Auditd Configuration
Fail2Ban
Ubuntu User Management
SSH Hardening