ubuntu-server-hardening.md

Ubuntu Server Hardening

Securing BIOS:

• Preventing Changes to BIOS Settings
• Preventing System Booting

Securing the BIOS (Basic Input/Output System) settings is crucial for protecting the system's firmware from unauthorized access and tampering. However, it's important to note that the BIOS setup process can vary significantly depending on the hardware manufacturer and model. BIOS settings are not controlled by the operating system (like Ubuntu) but are specific to the hardware.

Here are some general steps you can take to enhance the security of the BIOS:

1. Set a BIOS Password: Most BIOS setups allow you to set a password. This password will be required to access the BIOS settings during the boot process. The exact steps to set a BIOS password vary depending on the manufacturer and model of your motherboard. Consult your motherboard's manual or the manufacturer's website for instructions.

2. Disable Booting from External Devices: In the BIOS settings, you can often disable booting from external devices like USB drives or optical drives. This prevents someone from booting your system with a different operating system or a malicious tool. Look for options related to "Boot Order" or "Boot Priority" in your BIOS settings.

3. Set a Boot Password: Some BIOS setups allow you to set a password that is required before the system can boot. This adds an additional layer of security, even before the operating system starts. Similar to setting a BIOS password, the exact steps vary based on the hardware.

4. Lock BIOS Settings: Many BIOS setups allow you to lock the BIOS settings with a password. This prevents anyone from making changes to BIOS configurations without entering the password first. This is often called "Write Protect" or "Settings Lock."

5. Update BIOS Firmware: Keeping your BIOS firmware up to date is important for security. Manufacturers release updates to fix security vulnerabilities and improve system stability. Check the manufacturer's website for BIOS updates and follow their instructions for updating.

6. Physical Security: Ensure that physical access to the computer is restricted. Unauthorized physical access can allow someone to reset BIOS settings or perform other malicious actions.

7. Encryption and Secure Boot: Some modern systems support features like Secure Boot and TPM (Trusted Platform Module), which can enhance security by verifying the integrity of the boot process and system components.

Remember, the exact steps to perform these actions can vary depending on your hardware. Always refer to your motherboard's manual or the manufacturer's documentation for accurate instructions.

Keep in mind that BIOS security is a fundamental aspect of overall system security. While these steps help secure the BIOS, they should be part of a broader security strategy that includes maintaining a secure operating system, keeping software updated, and implementing security best practices.

Securing Non-BIOS-based Systems:

• Unified Extensible Firmware Interface

Securing systems that use the Unified Extensible Firmware Interface (UEFI) involves protecting the firmware and ensuring the system's boot process is secure. UEFI has replaced traditional BIOS on modern systems, providing more advanced features and security mechanisms. Here's how you can enhance security for UEFI-based systems in Ubuntu:

1. Secure Boot: Secure Boot is a UEFI feature that ensures only trusted software is allowed to run during the boot process. It helps prevent unauthorized or malicious code from running early in the startup sequence. To enable Secure Boot:

• Ensure that your hardware supports Secure Boot.
• Go to your system's UEFI/BIOS settings during boot (often by pressing a key like F2, F10, or Delete).
• Find the Secure Boot option and enable it.
• Import the manufacturer's Secure Boot keys or generate your own keys for signing trusted bootloaders and kernels.

2. Update Firmware (UEFI/BIOS): Regularly check for and apply firmware updates from your hardware manufacturer. These updates may include security patches that address vulnerabilities.

3. Firmware Password: Some UEFI systems allow you to set a password for accessing the UEFI settings. This adds an extra layer of security, preventing unauthorized changes to firmware settings.

4. Disable Unneeded UEFI Features: UEFI provides various features, and some may be unnecessary for your use case. Disabling unused features reduces the attack surface. For example, you might disable network boot if not required.

5. Check Boot Order: Make sure that the boot order is set to boot from the appropriate device (usually the system's primary hard drive or SSD) and that unnecessary boot options are disabled.

6. TPM (Trusted Platform Module): If your system has a TPM, you can use it to enhance security by storing encryption keys and verifying system integrity during boot.

7. Kernel and Bootloader Security: Ensure that the Linux kernel and bootloader are up to date. Enable features like Secure Boot and cryptographic verification of kernel modules (if available).

8. Physical Security: Protect physical access to the computer. Unauthorized physical access can allow an attacker to reset UEFI settings or perform other malicious actions.

9. Vendor-Specific Tools: Some hardware manufacturers provide additional tools for securing UEFI settings. Check the documentation for your system to see if any specific tools or features are available.

10. Follow Best Practices: Follow general security best practices, such as using strong passwords, keeping software updated, and using firewall settings to restrict network access.

Remember that UEFI settings and options can vary depending on the manufacturer and model of your hardware. Always consult your system's documentation for accurate instructions on securing UEFI settings.

Partitioning The Disk

• /boot, /tmp

Partitioning your disk in Ubuntu involves dividing your storage device into separate sections or partitions, each serving a specific purpose. The /boot and /tmp partitions are two such partitions that you might consider setting up for specific purposes.

If you have live Ubuntu server deployed on AWS and you want to add separate partitions for /boot and /tmp, the process will involve resizing existing partitions and creating new ones. Here's how you can do it:

Please be aware that partitioning operations can carry risks, and you should always backup your data and be cautious during the process.

1. Backup Important Data: Before you proceed with partitioning, ensure that you have backups of your important data. Partitioning operations can potentially result in data loss.

2. Create /tmp Partition: You can create a new partition for /tmp by utilizing the available space in your root partition. Use a partitioning tool like gparted to resize your root partition to free up space. This tool provides a graphical interface for managing disk partitions. Once you have free space, create a new partition and set its mount point to /tmp.

3. Create /boot Partition:

• Since you're using an AWS instance, it's important to consider the limitations of your storage device. If /dev/xvda is your root device, you'll need to check whether it can be resized without data loss. Amazon EBS volumes, for example, can usually be resized without much trouble.
• If your root volume allows resizing, follow the same process as with the /tmp partition. Resize your root partition to create unallocated space, then create a new partition and set its mount point to /boot.

4. Update /etc/fstab: After creating the new partitions, you'll need to update your /etc/fstab file to ensure that the new partitions are mounted at boot. You'll likely need to update the UUIDs of the partitions.

5. Reboot: Reboot your server to apply the changes you've made. Ensure that everything is working as expected, and that your new /tmp and /boot partitions are properly mounted.

6. Testing: After the reboot, make sure to test the functionality of the system, including booting, accessing /boot, and using /tmp. Make sure there are no unexpected issues.

Keep in mind that these steps can vary based on your specific AWS instance type, disk layout, and file system structure. Always take precautions, and if you're not entirely confident in performing these tasks, consider seeking assistance from someone experienced with Linux system administration and partitioning.

Configure Security Logon Banner

Logon Banner: A C C E S S W A R N I N G!!!!! This is a private computer system. Unauthorized access or use is prohibited and only authorized users are permitted. Use of this system constitutes consent to monitoring at all times and user should have no expectation of privacy. Unauthorized access or violations of security regulations is unlawful and hence if monitoring reveals either of it, appropriate disciplinary action will be taken against the users violating security regulations or making unauthorized use of this system.

1. Create a Script in /etc/update-motd.d/: Open a terminal or connect to your Ubuntu server via SSH and create a new script in the /etc/update-motd.d/ directory. The script name should start with a numeric prefix to control its order of execution. For example, create a script named 99-my-banner:

sudo nano /etc/update-motd.d/99-my-banner

2. Add the Banner Message to the Script: Inside the script, you can use standard shell commands to generate your custom banner message. For example, to display a simple welcome message, you can use echo commands:

#!/bin/sh
echo "********************************************************************************"
echo "A C C E S S   W A R N I N G!!!!!"
echo "This is a private computer system. Unauthorized access or use is prohibited and only authorized users are permitted. Use of this system constitutes consent to monitoring at all times and user should have no expectation of privacy. Unauthorized access or violations of security regulations is unlawful and hence if monitoring reveals either of it, appropriate disciplinary action will be taken against the users violating security regulations or making unauthorized use of this system."
echo "********************************************************************************"

Save the file and exit the text editor.

3. Set Appropriate Permissions:

Ensure the script is executable:

sudo chmod +x /etc/update-motd.d/99-my-banner

4. Test the Banner: To test the banner, you can either log out and log back in, or you can force the update by running the following command:

sudo run-parts /etc/update-motd.d/

The custom banner message will be displayed after a successful login.

5. (Optional) Disable Other MOTD Scripts: By default, Ubuntu includes several scripts in the /etc/update-motd.d/ directory that generate system information. If you prefer to show only your custom banner, you can remove or disable the other scripts. For example, you can move the existing scripts to a different directory:

sudo mkdir /etc/update-motd.d-backup
sudo mv /etc/update-motd.d/* /etc/update-motd.d-backup/

Note: Disabling or removing existing MOTD scripts may hide useful system information for your users. Be cautious and consider the impact on your server administration.

Post-Installation Procedures

In Ubuntu, the package manager is apt (Advanced Package Tool) and the default firewall management tool is ufw (Uncomplicated Firewall). Here are the equivalent post-installation procedures for Ubuntu:

1. Update Packages: To update your system packages, use the apt package manager:

sudo apt update
sudo apt upgrade

To check the current and installed kernel versions on an Ubuntu system, you can use the uname and dpkg commands respectively. Here's how:

• To check the current kernel version (the kernel currently running on your system), use the uname command with the -r option:

uname -r

This will display the current kernel version, such as "5.4.0-81-generic".

• To list all installed kernel packages on your Ubuntu system, use the dpkg command with grep to filter for packages whose name starts with "linux-image":

dpkg -l | grep linux-image

This will show a list of installed kernel packages along with their version numbers. The current kernel (from the previous step) will be marked with "ii" in the first column.

Example output:

ii  linux-image-5.4.0-81-generic    5.4.0-81.91
ii  linux-image-5.4.0-84-generic    5.4.0-84.94

The version number is listed in the second column.

Please note that the actual output might vary based on your Ubuntu version and any kernel updates you have installed.

2. Enable and Start Firewall (ufw): ufw is a front-end for managing iptables firewall rules in Ubuntu. To enable and start ufw, follow these steps:

sudo ufw enable
sudo ufw status

The enable command turns on the firewall, and status will show the current firewall rules and status.

3. Disable Unnecessary Services: Ubuntu, like CentOS, allows you to disable services you do not need to improve security and reduce potential attack surfaces. To disable a service, use the systemctl command.

For example, to disable the CUPS (Common UNIX Printing System) service, you can run:

sudo systemctl disable cups

Replace cups with the service name you want to disable.

Remember that before disabling any service, you should carefully consider whether you truly do not need it, as some services might be required for specific functionalities of your system or applications.

Securing the Boot Loader

Securing the GRUB 2 bootloader in Ubuntu by setting a password to prevent unauthorized access to its console involves a few steps. Here's how you can do it:

1. Generate an Encrypted Password:

First, you need to generate an encrypted password that GRUB will use for authentication. You can do this using the grub-mkpasswd-pbkdf2 command. Open a terminal and enter the following command:

grub-mkpasswd-pbkdf2

You'll be prompted to enter a password, and the command will generate an encrypted string. Keep this encrypted string handy, as you'll need it later.

2. Edit the GRUB Configuration:

Open the GRUB configuration file using a text editor. You'll need administrative privileges to do this, so use the sudo command:

sudo nano /etc/default/grub

3. Configure the GRUB Password:

In the configuration file, look for the line that starts with GRUB_CMDLINE_LINUX. Add the following options to the line:

GRUB_CMDLINE_LINUX="password_pbkdf2 root (hd0,1) your_encrypted_password"

Replace (hd0,1) with the appropriate disk and partition for your system (use GRUB-style notation, such as (hd0,1) for the first hard drive and second partition).

Replace your_encrypted_password with the encrypted password generated in step 1.

4. Update GRUB Configuration:

After making the changes, save the file and exit the text editor.

Update the GRUB configuration by running the following command:

sudo update-grub

5. Reboot:

Reboot your system to apply the changes:

sudo reboot

6. Test the Password Protection:

After rebooting, you should see a GRUB menu with a locked command line. To access the command line, press c and then enter the ls command to list the partitions. You'll be prompted to enter the password. Once you enter the correct password, you'll gain access to the GRUB command line.

This process will help you secure the GRUB 2 bootloader in Ubuntu by password-protecting the access to its console. Keep in mind that physical access to the system can potentially bypass this protection, so it's just one layer of security.

Password Security

In Linux systems, including Ubuntu, the /etc/passwd and /etc/shadow files are critical for user account management and password security. However, there are certain measures you can take to enhance password security and protect these files:

1. Limit Access to /etc/shadow:

The /etc/shadow file stores the hashed passwords and other security-related information for user accounts. This file should only be accessible by the root user and the shadow group. You can use the following command to set the appropriate permissions:

sudo chown root:shadow /etc/shadow
sudo chmod 640 /etc/shadow

This ensures that only the root user and members of the shadow group have read access to the file.

2. Limit Access to /etc/passwd:

The /etc/passwd file contains basic user account information. While it doesn't store passwords directly, it's still important to limit access to this file. You can set the following permissions:

sudo chown root:root /etc/passwd
sudo chmod 644 /etc/passwd

This allows read access to all users but only root can modify the file.

Forcing Strong Passwords:

Enforce users to change password every 30 days or less

$ sudo vi /etc/login.defs
...
PASS_MAX_DAYS   30

To enforce a strong password policy in Ubuntu, you can use the libpwquality library and the pam_pwquality PAM module (Pluggable Authentication Modules). This will allow you to set requirements such as minimum password length, minimum character classes, and check for character sequences and consecutive characters.

To enforce strong password policies through the PAM configuration, follow these steps:

1. Install libpwquality:

sudo apt update
sudo apt -y install libpam-pwquality cracklib-runtime

2. Backup PAM Configuration Files:

Before making any changes, create backups of the PAM configuration files you intend to modify. This will allow you to revert to the original configuration if needed.

sudo cp /etc/pam.d/common-password /etc/pam.d/common-password.bak
sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak

3. Edit the PAM Configuration File:

Open the /etc/pam.d/common-password file in a text editor:

sudo nano /etc/pam.d/common-password

Locate the line that contains password requisite pam_pwquality.so and comment it out or remove it:

# password requisite pam_pwquality.so retry=3

Then, add the following lines at the end of the file to enforce the desired password complexity requirements:

password requisite pam_pwquality.so retry=3 minlen=8 maxrepeat=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1 difok=3 gecoscheck=1 reject_username enforce_for_root

Save and close the file.

Options used:

• retry=3: Prompt a user 3 times before returning with error.
• minlen=8 : The password length cannot be less than this parameter
• maxrepeat=3: Allow a maximum of 3 repeated characters
• ucredit=-1 : Require at least one uppercase character
• lcredit=-1 : Must have at least one lowercase character.
• dcredit=-1 : must have at least one digit
• difok=3 : The number of characters in the new password that must not have been present in the old password.
• gecoscheck=1: Words in the GECOS field of the user’s passwd entry are not contained in the new password.
• reject_username: Rejects the password if contains the name of the user in either straight or reversed form.
• enforce_for_root: Enforce pasword policy for root user

4. Edit common-auth File:

If you want to enforce password complexity requirements during the user's initial login or password change, you can also modify the common-auth file:

sudo nano /etc/pam.d/common-auth

Add the following line at the top of the file:

auth requisite pam_pwquality.so retry=3

This will ensure that users are prompted to set a strong password when they create a new account or change their password.

Save and close the file.

5. Configure pwquality.conf:

Open the pwquality.conf file in a text editor:

sudo nano /etc/security/pwquality.conf

Add the following lines to set the desired password policy options:

minlen = 8
minclass = 4
maxsequence = 3
maxrepeat = 3

Save the file and exit the text editor.

6. Restart the Authentication Service:

After making the above changes, restart the authentication service to apply the modifications:

sudo systemctl restart systemd-logind

7. Test the Password Policy:

After making the changes, test the new password policy by creating a new user or changing the password for an existing user. The system should enforce the specified complexity requirements during the process.

Note: While switching user su – <username> if you see any error such as su: Module is unknown, undo the changes done to common-auth file. Restart the systemd-logind service and try again to switch.

Keep in mind that manually editing PAM configuration files can be powerful, but it requires careful attention to avoid misconfigurations that could lead to unintended consequences. Always make backups and test your changes to ensure that the desired behavior is achieved.

Configuring Password Aging

In Ubuntu, you can use the chage command to configure password aging for a user account. The chage command allows you to set various password-related attributes, including the password expiration date, minimum and maximum password age, and warning period before the password expires.

To configure the password aging for a user account to match your Active Directory policy or set it to at least 30 days, follow these steps:

1. Check Current Password Aging Settings:

Before making any changes, you can check the current password aging settings for a specific user account using the chage -l command:

sudo chage -l username

Replace username with the actual username of the account you want to check.

2. Set Password Expiration Date:

To configure the password expiration date for a user, use the chage -E option followed by the desired expiration date in YYYY-MM-DD format:

sudo chage -E YYYY-MM-DD username

Replace YYYY-MM-DD with the desired date for the password to expire and username with the actual username of the account.

3. Set Minimum and Maximum Password Age:

You can set the minimum and maximum password age using the chage -m and chage -M options, respectively:

sudo chage -m MIN_DAYS username
sudo chage -M MAX_DAYS username

Replace MIN_DAYS and MAX_DAYS with the desired values for the minimum and maximum password age, and username with the actual username of the account.

For example, to set the minimum password age to 1 day and the maximum password age to 30 days:

sudo chage -m 1 username
sudo chage -M 30 username

4. Set Password Expiry Warning Period: You can set the number of days before the password expires that the user will receive a warning using the chage -W option:

sudo chage -W DAYS username

Replace DAYS with the desired number of days for the warning period and username with the actual username of the account.

For example, to set a warning period of 7 days:

sudo chage -W 7 username

After configuring the password aging settings using the chage command, the user's password will expire based on the specified configurations, and they will be prompted to change their password accordingly.

Account Locking

To implement a lockout policy for non-root users after three unsuccessful login attempts and an automatic unlock after 10 minutes on an Ubuntu server, you can follow these steps:

Here are the steps to set up user lockout using pam_faillock:

1. PAM Modules Installation:

Check if the pam_faillock module is installed on your system. If not, you might need to install it. On Ubuntu, you can install it with:

sudo apt-get install libpam-modules

2. Edit PAM Configuration:

Open the PAM configuration file for SSH:

sudo nano /etc/pam.d/sshd

3. Add the Lockout Rules:

Add the following lines at the top of the file:

auth required pam_faillock.so preauth audit silent deny=3 unlock_time=600
auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600

4. Restart Service:

After making changes to PAM configuration files, you need to restart the corresponding service to apply the changes. For SSH, you can restart it with:

sudo service ssh restart

5. Testing the Lockout:

Make sure you're using a non-root user (like "webadmin") to test this. If you're logged in as root, the rules won't apply to the root account. Attempt incorrect logins to trigger the lockout. Enter the wrong password three times. Wait for the specified lockout time (600 seconds = 10 minutes).

After the lockout time has passed, attempt to log in again with the correct password.

6. Check User's Lockout Status:

Use the faillock command to check the lockout status of a specific user. Replace username with the actual username you want to check:

sudo faillock --user username

7. To check if an account is locked on a Linux system, you can use the passwd command with the -S option followed by the username. This will display information about the account's password status, including whether it's locked. Here's how you can do it:

passwd -S <username>

• Example:

# passwd -S webadmin
webadmin P 08/03/2023 1 30 7 -1

1. P: This indicates that the password is in a usable state.

2. 08/03/2023: The date when the password was last changed.

3. 1: The minimum number of days before the password can be changed.

4. 30: The maximum number of days after which the password must be changed.

5. 7: The number of days before the password expires during which the user will be warned about the expiration.

6. -1: The number of days after the password expires during which the user can still change the password (negative value indicates that there's no enforcement).

If an account is locked, the output would typically show "L" or "LK" in place of "P" to indicate that the password is locked.

8. Check Logs: Monitor the system logs for any relevant error messages. The logs can provide insights into what might be causing the issue. Check /var/log/auth.log or similar files for authentication-related information.

9. Reboot: In some cases, a reboot might help apply PAM changes and clear any issues that might be causing unexpected behavior.

Enabling Automatic Logouts

Set an environment variable TMOUT with a value of 300 seconds (5 minutes), and then make it readonly to ensure that it cannot be changed during the user's session. This method applies to all users on the system using the bash shell.

Here's a summary of the steps to enable automatic logouts after 300 seconds using /etc/profile:

1. Open a terminal or connect to your Ubuntu machine via SSH.

2. As the root user or using sudo, edit the /etc/profile file with a text editor:

sudo nano /etc/profile

3. Add the following lines at the end of the file:

export TMOUT=300
readonly TMOUT

4. Save the file and exit the text editor.

5. The changes will take effect the next time users log in or start a new shell session. After 300 seconds of inactivity, the shell will automatically log out the user.

Please note that this method will only work for users who use the bash shell. If your system uses a different shell for some users, you may need to set TMOUT in the respective shell configuration file (e.g., ~/.bashrc for individual users) or apply a different approach based on the shell in use.

Disallowing Root Access

Disabling direct root access in Ubuntu is a crucial security practice. Here are the steps to disallow root access:

1. Create a Non-Root User:

If you haven't already, create a non-root user with administrative privileges. This user will be used to perform administrative tasks using the sudo command.

sudo adduser yourusername
sudo usermod -aG sudo yourusername

Replace yourusername with the desired username.

2. Ensure Password Authentication for SSH:

Make sure password authentication is enabled for SSH. Open the SSH configuration file:

sudo nano /etc/ssh/sshd_config

Find the line that says PasswordAuthentication and make sure it's set to yes:

PasswordAuthentication yes

Save the file and restart the SSH service:

sudo systemctl restart ssh

3. Test Non-Root User Access:

Logout from the server and try logging in using the non-root user:

ssh yourusername@server_ip

You should be able to log in using the password of the non-root user.

4. Disable Direct Root Login:

Open the SSH configuration file again:

sudo nano /etc/ssh/sshd_config

Find the line that says PermitRootLogin and change it to:

PermitRootLogin no

Save the file and restart the SSH service:

sudo systemctl restart ssh

This prevents the root user from logging in directly via SSH.

5. Use sudo for Administrative Tasks:

Whenever you need to perform administrative tasks, use the sudo command followed by the command you want to run with elevated privileges:

sudo command_to_run

You'll be prompted to enter the password of the non-root user.

6. Ensure Key-Based Authentication (Optional):

For even stronger security, set up key-based authentication and disable password authentication. This prevents unauthorized access even more effectively.

7. Regularly Update and Monitor:

Keep your system updated with security patches, monitor system logs for any unusual activity, and maintain good security practices.

Securing LDAP

LDAP stands for Lightweight Directory Access Protocol. It's an open and widely-used protocol for accessing and maintaining directory information services over a network. In the context of Ubuntu and other Linux-based systems, LDAP is often used as a centralized authentication and directory service to manage user accounts, groups, and other network-related information.

Securing LDAP (Lightweight Directory Access Protocol) involves several steps to ensure the confidentiality, integrity, and availability of the directory service. Below are steps you can follow to secure LDAP on an Ubuntu system:

1. Install LDAP Server (if not already installed):

If you haven't installed an LDAP server yet, you can choose from various LDAP server implementations such as OpenLDAP. Here's how to install OpenLDAP:

sudo apt-get update
sudo apt-get install slapd ldap-utils

2. Configure TLS/SSL Encryption:

Transport Layer Security (TLS) or Secure Sockets Layer (SSL) encryption ensures that data transmitted between the LDAP client and server is secure.

• During the installation of OpenLDAP, you will be prompted to configure TLS. Follow the prompts to set up a certificate.

• If you need to configure TLS later, you can do so using the dpkg-reconfigure command:

sudo dpkg-reconfigure slapd

3. Restrict Access with Access Control Lists (ACLs):

Define access control rules to restrict who can access and modify data in the LDAP directory. ACLs are configured in the LDAP directory itself.

• The ACL configuration is typically found in the cn=config subtree. • You can use the ldapmodify tool to add or modify ACLs.

4. Use Strong Password Policies:

Implement strong password policies to ensure that user passwords meet complexity requirements and are regularly updated.

• Configure password policies in your LDAP server's configuration. In OpenLDAP, you can use the ppolicy overlay.

5. Regularly Monitor Logs:

Regularly review LDAP server logs to detect and respond to any suspicious or unauthorized activities.

6. Backup and Disaster Recovery:

Implement a regular backup strategy for your LDAP data to ensure data recovery in case of failures.

7. Regularly Update and Patch:

Keep your operating system and LDAP server software up to date with the latest security patches.

8. Network Security:

Implement firewall rules to control which systems can access the LDAP server. If your LDAP server is publicly accessible, consider using a Virtual Private Network (VPN) or other secure methods to access it.

9. Implement Intrusion Detection/Prevention Systems (IDS/IPS):

Utilize IDS/IPS solutions to monitor network traffic and detect potential attacks on your LDAP server.

10. Authentication and Authorization:

Use LDAP for authentication and authorization purposes. Configure applications and services to authenticate users against your LDAP directory.

Remember that securing LDAP is an ongoing process. It's important to continuously monitor, review, and update your security measures to stay protected against emerging threats. If you're not experienced with LDAP, consider seeking assistance from professionals or resources dedicated to LDAP security best practices.

Securing NFS Mount

Securing NFS (Network File System) mounts is essential to prevent unauthorized access and protect your data. Here's how you can secure NFS mounts on an Ubuntu system:

1. Use NFSv4:

NFSv4 offers improved security features compared to older versions. Whenever possible, use NFSv4 for your mounts.

2. Configure /etc/exports:

Open the /etc/exports file using a text editor with root privileges:

sudo nano /etc/exports

Define your NFS exports with appropriate options. You can specify options like ro (read-only), no_root_squash (allows root access), and no_subtree_check (disables subtree checking):

/path/to/shared/folder   client_ip(options)

• For example:

/data   192.168.1.100(rw,sync,no_subtree_check)

Save the file.

3. Apply Changes:

After editing /etc/exports, apply the changes using the following command:

sudo exportfs -a

4. Firewall Configuration:

If you're using a firewall, you need to allow the necessary ports for NFS. NFSv4 requires both TCP and UDP ports 2049, and optional ports 20048 (mountd) and 2048 (status).

For example, using ufw:

sudo ufw allow proto tcp from client_ip to any port 2049
sudo ufw allow proto udp from client_ip to any port 2049

5. Secure the NFS Server:

Limit access to the NFS server using host-based restrictions in /etc/hosts.allow and /etc/hosts.deny.

In /etc/hosts.allow, allow specific clients:

nfs: client_ip

In /etc/hosts.deny, deny all other clients:

nfs: ALL

6. Enable Kerberos Authentication (Optional):

If security is a top concern, consider enabling Kerberos authentication for NFS. This adds an extra layer of authentication and encryption.

7. Regularly Monitor and Update:

Regularly monitor logs for any unauthorized access attempts. Keep your system updated with the latest security patches.

8. Testing and Verification:

Test the NFS mounts from the client side to ensure they are accessible as expected.

Securing the Apache HTTP Server

In Ubuntu, the process of securing the Apache HTTP Server (Apache2) is quite similar to other Linux distributions, with a few differences in file locations and package names. Here's how you can achieve the same steps on Ubuntu:

1. Change Ownership and Permissions:

If you want to ensure that only the root user has write permissions to a directory containing scripts or CGIs, follow these commands:

sudo chown root:<your_group> /path/to/directory
sudo chmod 755 /path/to/directory

Replace <your_group> with the appropriate group name if you want to assign a specific group ownership. The chmod 755 command sets the permissions to allow read, write, and execute for the owner (root), and read and execute for others.

2. Configure Apache:

The Apache configuration files on Ubuntu are located in the /etc/apache2/ directory. The main configuration file is apache2.conf. You can configure Apache options there or in separate files located in the /etc/apache2/conf-available/ and /etc/apache2/conf-enabled/ directories.

You can use a text editor like nano or vim to edit these files:

sudo nano /etc/apache2/apache2.conf

3. Apply Appropriate Options:

Inside the Apache configuration files, you can specify various options related to security and other settings. These options can include settings for Directory access, Script execution, CGI execution, and more. The specific options you need to set will depend on your configuration and security requirements.

For example, you might use directives like Options, Require, Allow, and Deny within the <Directory> sections to control access to specific directories.

For instance, you could have something like:

<Directory /path/to/directory>
    Options -Indexes +FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>

This configuration denies all access to the specified directory. You can modify these directives to suit your needs.

4. Restart Apache:

After making changes to the Apache configuration, you need to restart the Apache service for the changes to take effect:

sudo service apache2 restart

Remember that securing a web server involves a comprehensive approach, including firewall settings, regular updates, monitoring, and more. Always ensure you have a backup and thoroughly test any changes to avoid accidental disruptions.

TLS Settings

On Ubuntu, the Apache HTTP Server configuration is split into multiple files stored in the /etc/apache2/ directory. The specific file to configure SSL settings is typically /etc/apache2/sites-available/default-ssl.conf or /etc/apache2/sites-available/default-ssl.

Here's how you can enable TLSv1.2 and configure SSL settings on Ubuntu:

1. Open the appropriate SSL configuration file for editing. You'll likely need administrative privileges to edit this file, so use sudo or root access:

sudo nano /etc/apache2/sites-available/default-ssl.conf

2. Inside the SSL configuration file, look for the <VirtualHost> block that contains the SSL settings. Look for the SSLEngine on directive, and below it, you can add the SSLProtocol directive to enable TLSv1.2 and disable older protocols:

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    # Existing SSL configuration lines...
    SSLEngine on

    # Add the SSLProtocol directive to enable TLSv1.2 and disable older protocols
    SSLProtocol -All +TLSv1.2

    # Other SSL settings...
  </VirtualHost>
</IfModule>

Save the changes and exit the text editor (in nano, press Ctrl + O, then Enter, and Ctrl + X).

3. After making changes to the configuration, it's essential to check the syntax for errors:

sudo apachectl configtest

If the output says "Syntax OK," your configuration changes are valid.

4. If you modified the default-ssl.conf file, you need to enable the SSL site and restart Apache:

sudo a2ensite default-ssl
sudo systemctl restart apache2

Alternatively, if you have a different site configuration file specifically for SSL (e.g., my-ssl-site.conf), enable that site instead.

Cipher Suites

To configure the SSLCipherSuite in Ubuntu's Apache HTTP Server, you can follow these steps:

1. Open the httpd-ssl.conf file for editing. You'll likely need administrative privileges to edit this file, so use sudo or root access:

sudo nano /etc/apache2/sites-available/default-ssl.conf

4 2. Inside the httpd-ssl.conf file, locate the <VirtualHost> block that contains the SSL settings. Look for the SSLEngine on directive, and below it, add the SSLCipherSuite directive with the appropriate cipher suites:

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    # Existing SSL configuration lines...
    SSLEngine on

    # Add the SSLCipherSuite directive with the desired cipher suites
    SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256

    # Other SSL settings...
  </VirtualHost>
</IfModule>

Save the changes and exit the text editor (in nano, press Ctrl + O, then Enter, and Ctrl + X).

3. After making changes to the configuration, it's essential to check the syntax for errors:

sudo apachectl configtest

If the output says "Syntax OK," your configuration changes are valid.

4. If you modified the default-ssl.conf file, you need to enable the SSL site and restart Apache:

sudo a2ensite default-ssl
sudo systemctl restart apache2

Alternatively, if you have a different site configuration file specifically for SSL (e.g., my-ssl-site.conf), enable that site instead.

Disable Cross Site Scripting

To apply the specific HTTP response headers for disabling Cross-Site Scripting (XSS) and enhancing security, you can use the following steps:

1. Open the default configuration file for Apache, apache2.conf, for editing. You'll likely need administrative privileges to edit this file, so use sudo or root access:

sudo nano /etc/apache2/apache2.conf

2. Inside the apache2.conf file, look for the <Directory> section that corresponds to the web root directory (/var/www/html by default).

If you didn't find a specific <Directory /var/www/html> section inside the apache2.conf file, you have a couple of options for adding the HTTP response headers.

Option 1: Add Headers to Existing <Directory /var/www/> Section You can add the HTTP response headers directly inside it. You can apply these headers to the entire /var/www/ directory, including its subdirectories, and any files served from that directory will have the specified headers:

<Directory /var/www/>
    # Add the following lines to set the desired HTTP response headers
    Header always set X-XSS-Protection "1; mode=block"
    Header always set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"

    # Other configurations for the /var/www/ directory...
</Directory>

Option 2: Create a New <Directory /var/www/html> Section If you prefer to apply the headers only to the /var/www/html directory specifically, you can create a new <Directory> section for it:

<Directory /var/www/html>
    # Add the following lines to set the desired HTTP response headers
    Header always set X-XSS-Protection "1; mode=block"
    Header always set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"
</Directory>

Note: Both options should work, but the choice depends on whether you want the headers to apply to the entire /var/www/ directory or just the /var/www/html/ directory. If you want the headers to apply only to the HTML directory, create the new section. Otherwise, add them to the existing <Directory /var/www/> section.

After making the necessary changes, save the apache2.conf file, and check the syntax for errors:

sudo apachectl configtest

If you get following error in syntax:

Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration Action 'configtest' failed.

Follow below steps to resolve: The Header directive is provided by the mod_headers module in Apache. This module allows you to manipulate HTTP request and response headers.

To resolve this issue and use the Header directive in your Apache configuration, you need to ensure that the mod_headers module is loaded and enabled. Follow these steps to enable the mod_headers module on Ubuntu:

1. Enable the mod_headers module:

sudo a2enmod headers

2. Restart Apache to apply the changes:

sudo systemctl restart apache2

Now, the mod_headers module should be loaded, and the Header directive should work without any errors. You can verify the configuration again using:

sudo apachectl configtest

3. If there are no syntax errors, Apache will show "Syntax OK," and your configuration is valid, restart Apache to apply the changes:

sudo systemctl restart apache2

Transport Policies

To apply the specified transport policies in Ubuntu's Apache HTTP Server, you can follow these steps:

1. Open the default configuration file for Apache, apache2.conf, for editing. You'll likely need administrative privileges to edit this file, so use sudo or root access:

sudo nano /etc/apache2/apache2.conf

2. Inside the apache2.conf file, locate the <Directory> section that corresponds to the web root directory (/var/www/html by default). If you cannot find it, you can add it at the end of the file:

# Other configurations...

<Directory /var/www/html>
    # Add the following lines to set the desired transport policies
    FileETag None
    TraceEnable off
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-permitted-Cross-Domain-Policies "master-only"
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"

    # Other configurations for the web root directory...
</Directory>

# Add TraceEnable directive here
TraceEnable off

# More configurations...

Note: The TraceEnable directive is a server-level configuration, not specific to a particular directory. It should be placed in the main server configuration file (apache2.conf or httpd.conf) or in an appropriate global context, outside of any <Directory> or <VirtualHost> blocks.

Save the changes and exit the text editor (in nano, press Ctrl + O, then Enter, and Ctrl + X).

3. After making changes to the configuration, it's essential to check the syntax for errors:

sudo apachectl configtest

If the output says "Syntax OK," your configuration changes are valid.

4. If you modified the apache2.conf file, you need to restart Apache for the changes to take effect:

sudo systemctl restart apache2

By adding these transport policies to your Apache configuration, you enhance the security and control how the server handles certain aspects of HTTP responses:

• FileETag None: This disables ETags, which are used for cache validation. By setting None, you prevent the disclosure of file metadata in ETags.

• TraceEnable off: This disables the TRACE method, which could be used in cross-site tracing attacks.

• Strict-Transport-Security: This header tells the browser to enforce HTTPS for the specified duration (max-age). It also includes subdomains (includeSubDomains) in the enforcement.

• X-permitted-Cross-Domain-Policies: This header specifies the permitted cross-domain policies for Adobe Flash and Acrobat. By setting it to "master-only", you only allow the site's master policy.

• Cache-Control, Pragma: These headers instruct the browser and proxies to not cache the response, ensuring that clients always request fresh content from the server.

Make sure to apply these policies in the appropriate context and directories within your Apache configuration to suit your security requirements.

Cryptographic Login

Cryptographic Login will enhance the security of your SSH connections.

1. Enable Cryptographic Key-Based Authentication:

Open the SSH configuration file for editing:

sudo nano /etc/ssh/sshd_config

Locate the PubkeyAuthentication directive and ensure it's set to yes:

PubkeyAuthentication yes

Save the file and exit the text editor.

2. Disable Password-Based Authentication:

Still in the same /etc/ssh/sshd_config file, find the PasswordAuthentication directive and set it to no:

PasswordAuthentication no

This ensures that users cannot log in using passwords.

3. Reload SSH Configuration:

After making these changes, you need to reload the SSH service for the changes to take effect:

sudo systemctl reload ssh

Now, users will only be able to authenticate using cryptographic keys. Keep in mind that before disabling password authentication, you should ensure that you have set up SSH key-based authentication for all the users who need access.

This configuration significantly improves the security of your SSH connections, as cryptographic keys are more secure than passwords and less susceptible to common attacks like brute force attempts.

Protocol Version for SSH

SSH (Secure Shell) supports several protocol versions, each introducing different features and security enhancements. The most commonly used SSH protocol versions are SSH-1 and SSH-2.

1. SSH-1:

SSH-1 was the first version of the SSH protocol, introduced in the 1990s. It provided a secure replacement for insecure remote login protocols like Telnet and rsh (remote shell). However, SSH-1 had several security flaws, and it is considered obsolete and insecure. It is no longer recommended or widely used due to its vulnerabilities.

2. SSH-2:

SSH-2 is the modern and widely adopted version of the SSH protocol. It addressed the security weaknesses of SSH-1 and introduced several improvements, including enhanced encryption algorithms, stronger authentication methods, and support for additional security features like port forwarding, X11 forwarding, and file transfer (SCP and SFTP). SSH-2 is the version used by default in modern SSH implementations.

SSH-2 is backward compatible, meaning it can communicate with older SSH-1 servers, but most modern SSH clients and servers default to using SSH-2. SSH-1 is rarely used today due to its inherent security risks.

When you connect to an SSH server, the client and server negotiate the highest compatible protocol version they both support. Typically, the SSH clients and servers in use today will use SSH-2, but it's essential to keep your SSH software up-to-date to benefit from the latest security features and improvements.

For security reasons, it's crucial to disable SSH-1 support on SSH servers, and many modern SSH server configurations have SSH-1 support disabled by default.

To check the protocol version used by your SSH client, you can use the -V option:

ssh -V

To check the protocol version supported by an SSH server, you can inspect the server's SSH configuration file (usually located at /etc/ssh/sshd_config) and look for the following line:

Protocol 2

The "Protocol 2" line in the SSH server configuration indicates that the server supports SSH-2, and SSH-1 is disabled.

Or you can run the following command to list the lines containing "Protocol" in the sshd_config file:

root@ubuntu-hardening:/# cat /etc/ssh/sshd_config | grep -i "protocol"

If you are unable to find the "Protocol 2" line in the sshd_config file, it likely means that the configuration is using the default value, which is equivalent to supporting "SSH-2" and disabling "SSH-1".

In the absence of the "Protocol" line in the sshd_config file, OpenSSH (the most commonly used SSH server implementation) assumes the default value of supporting only "SSH-2" and disabling "SSH-1".

Disabling Source Routing

To implement the security measures you've mentioned on an Ubuntu server, follow these steps:

1. Disabling Source Routing:

Add the following lines to the /etc/sysctl.conf file to drop packets with Strict Source Routing (SSR) and Loose Source Routing (LSR) options set:

# Drop packets with SSR and LSR options set
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

After adding these lines, apply the changes using the sysctl command:

sudo sysctl -p

This will disable the acceptance of packets with source routing options.

2. Disabling Packet Forwarding:

To disable forwarding of IPv4 and IPv6 packets on all interfaces, you can add the following lines to the /etc/sysctl.conf file:

# Disable packet forwarding
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

Apply the changes using the sysctl command:

sudo sysctl -p

This will disable packet forwarding on your system.

3. Disabling Multicast Packets:

To disable forwarding of all multicast packets on all interfaces, you can add the following lines to the /etc/sysctl.conf file:

# Disable forwarding of multicast packets
net.ipv4.conf.all.mc_forwarding = 0
net.ipv6.conf.all.mc_forwarding = 0

Apply the changes using the sysctl command:

sudo sysctl -p

This will disable the forwarding of multicast packets on all interfaces.

These changes will help improve the security of your server by disabling source routing, packet forwarding, and multicast packet forwarding. Make sure to thoroughly test your server after applying these changes to ensure that there are no unintended consequences.

Errors:

# Error1
sysctl: cannot stat /proc/sys/net/ipv6/conf/all/accept_source_route: No such file or directory

If you are not using IPv6 on your server or if you have it disabled, you can safely ignore this error. The absence of the /proc/sys/net/ipv6/conf/all/accept_source_route file simply means that the IPv6 settings related to source routing are not applicable on your system.

# Error2
sysctl: setting key "net.ipv4.conf.all.mc_forwarding": No such file or directory

Multicast forwarding is typically related to routers and systems acting as routers. If your system is not functioning as a router and is not involved in multicast routing, you can safely ignore this error.

Disable IPv6

In Ubuntu, the steps to disable IPv6 are slightly different from those in other Linux distributions. Follow these steps to disable IPv6 in Ubuntu:

Open the sysctl.conf file for editing:

sudo nano /etc/sysctl.conf

Add the following lines to disable IPv6:

# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Save the changes and exit the text editor.

Apply the sysctl settings to the current session:

sudo sysctl -p

To disable IPv6 in network interfaces, you can add the following line to the /etc/sysctl.conf file as well:

# Disable IPv6 for all interfaces
net.ipv6.conf.all.disable_ipv6 = 1

Restart the network service:

sudo service networking restart

To disable IPv6 in the GRUB configuration, open the GRUB default file for editing:

sudo nano /etc/default/grub

Find the line starting with GRUB_CMDLINE_LINUX, and add ipv6.disable=1 to the existing parameters, ensuring they are separated by spaces. For example:

GRUB_CMDLINE_LINUX="ipv6.disable=1 quiet splash"

Save the changes and exit the text editor.

Update the GRUB configuration:

sudo update-grub

Reboot your system:

sudo reboot

Enable System Auditing

Ubuntu uses auditd, but the configuration and service management commands are adapted to Ubuntu's package management system (systemd). Here are the steps to enable and configure the auditd service in Ubuntu:

1. Install auditd (if not already installed):

sudo apt-get update
sudo apt-get install auditd

2. Configure auditd:

The configuration file for auditd in Ubuntu is /etc/audit/auditd.conf. You can edit this file to configure the parameters according to your requirements. Use a text editor like nano or vim:

sudo nano /etc/audit/auditd.conf

Here are some common parameters you might want to configure:

• log_file: Set the log file location.
• max_log_file: Set the maximum log file size in MB.
• max_log_file_action: Define the action to take when the maximum log file size is reached (e.g., rotate, keep_logs).
• space_left: Set the threshold for disk space usage.
• space_left_action: Define the action to take when disk space runs low.
• admin_space_left: Set the threshold for administrative space usage.

Make your desired changes and save the file.

3. Start and Enable the auditd Service:

Start the auditd service:

sudo service auditd start

Enable auditd to start at boot:

sudo systemctl enable auditd

This will ensure that the auditd service is automatically started when the system boots up.

4. Verify auditd Status:

You can check the status of the auditd service:

sudo service auditd status

This will show you whether the service is active and running.

Please note that while the general steps are provided here, the specific parameters you configure in /etc/audit/auditd.conf will depend on your auditing requirements and security policies.

Also, the auditd service primarily records system-related events for auditing purposes. To audit user-level events and actions, you may need to configure additional audit rules. You can do this using the auditctl command. For more advanced auditing configurations, consider referring to official documentation or seeking guidance from experienced administrators or security experts.

Audit Rules

To configure audit rules in Ubuntu using the /etc/audit/audit.rules file and the /etc/audit/rules.d/ directory, you can follow these steps:

1. Understanding Rule Groups:

The /etc/audit/audit.rules file and the /etc/audit/rules.d/ directory are used to define different sets of audit rules. These rules specify what events to monitor and log. The numbers preceding the rule filenames indicate the priority and grouping of the rules.

• 10: Kernel and auditctl configuration
• 20: Rules that could match general rules but you want a different match
• 30: Main rules
• 40: Optional rules
• 50: Server-specific rules
• 70: System local rules
• 90: Finalize (immutable)

2. Configuring Audit Rules:

To add audit rules, follow these general steps:

• Open the desired rule file for editing using a text editor like nano or vim. For example, to edit the main audit rules:

sudo nano /etc/audit/rules.d/30-main.rules

• Add your audit rules to the file. Audit rules are specified in a format like:

-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -k access

This rule example logs attempts to access files that result in permission denied errors.

• Save the file.

3. Applying Rules:

After editing the rule files, you need to reload the audit configuration to apply the changes:

sudo service auditd reload

This will read the rule files and apply the new configurations.

4. Viewing Rules:

You can use the auditctl command to view currently loaded audit rules:

sudo auditctl -l

This will show the rules that are currently in effect.

Remember that configuring audit rules requires understanding the specific events you want to monitor and log. It's recommended to consult with security experts or references on audit rules to ensure you're setting up effective and relevant rules. Keep in mind that incorrect audit rule configurations can lead to excessive logging or missed security events.

Here are some example rules for each of the rule groups:

1. 10: Kernel and auditctl configuration:

These rules are typically used to configure global audit settings and set up initial monitoring.

• Enable auditd startup at boot:

# /etc/audit/rules.d/10-configuration.rules
-e 2

• Set auditd backlog limit:

# /etc/audit/rules.d/10-configuration.rules
-b 8192

2. 20: Rules that could match general rules but you want a different match:

These rules are used when you want specific rules to take precedence over more general rules.

• Log failed login attempts (preferably using a system-specific rule):

# /etc/audit/rules.d/20-specific-login.rules
-a always,exit -F arch=b64 -S sethostname -F success=0 -k login-failure

3. 30: Main rules:

These rules capture the core events you want to monitor. Note that these examples are basic; you might want to expand them based on your needs.

• Monitor file read and write actions:

# /etc/audit/rules.d/30-file-access.rules
-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -k file-access

• Monitor changes to system administration files:

# /etc/audit/rules.d/30-admin-files.rules
-a always,exit -F arch=b64 -S chmod,chown,chgrp,fchmod,fchown,fchownat -k admin-file-change

4. 40: Optional rules:

These rules can include additional events you consider important to monitor, but not critical.

• Monitor changes to network configuration:

# /etc/audit/rules.d/40-network.rules
-a always,exit -F arch=b64 -S sethostname,setdomainname -k network-change

5. 50: Server-specific rules:

These rules can be tailored to your server's specific requirements and services.

• Monitor changes to web server configuration files:

# /etc/audit/rules.d/50-web-server.rules
-a always,exit -F arch=b64 -S chmod,chown,chgrp,fchmod,fchown,fchownat -F path=/etc/nginx/* -k web-config-change

6. 70: System local rules:

These rules focus on local system actions that might be relevant to your environment.

• Monitor changes to user and group information:

# /etc/audit/rules.d/70-user-group.rules
-a always,exit -F arch=b64 -S useradd,usermod,userdel,groupadd,groupmod,groupdel -k user-group-change

7. 90: Finalize (immutable):

These rules are meant to enforce immutability on the audit configuration itself.

• Lock the audit configuration to prevent changes:

# /etc/audit/rules.d/90-finalize.rules
-e 2
-a always,exit -F arch=b64 -S auditctl -F success=0 -k audit-config-change

Remember that these are just examples, and you should tailor them to your environment's specific requirements. After adding or modifying rules, always reload the audit rules using sudo service auditd reload for the changes to take effect. Additionally, monitor the audit logs to ensure that the configured rules are capturing the desired events.

NTP

To add NTP (Network Time Protocol) on an Ubuntu instance, you can follow these steps to install and configure the NTP service:

Update the package list to ensure you have the latest available packages and install the NTP package:

sudo apt update
sudo apt install ntp

Once the installation is complete, the NTP service will start automatically. You can verify its status using the following command:

sudo systemctl status ntp

By default, the NTP service will automatically synchronize the system time with NTP servers from the pool.ntp.org project. The configuration file for NTP is located at /etc/ntp.conf.

(Optional) If you need to modify the NTP configuration, you can edit the /etc/ntp.conf file with a text editor like nano or vi:

sudo nano /etc/ntp.conf

In the configuration file, you can specify the NTP servers you want to use for time synchronization. By default, the pool.ntp.org servers are already included. If you need to use specific NTP servers, you can replace or add them like this:

server your_ntp_server_1
server your_ntp_server_2

Replace your_ntp_server_1 and your_ntp_server_2 with the addresses or hostnames of the NTP servers you want to use. Make sure to leave a blank line at the end of the file.

After making changes to the configuration, save the file and restart the NTP service:

sudo systemctl restart ntp

Check the status of the NTP service again to ensure it is running correctly:

sudo systemctl status ntp

The NTP service will now automatically synchronize the system time with the configured NTP servers, ensuring that your Ubuntu instance has accurate timekeeping. This is essential for various system processes, log management, and applications that rely on synchronized time across the network.

Example bash script to install and configure NTP

#!/bin/bash

# Install NTP
sudo apt-get update
sudo apt-get install -y ntp

# Backup the original ntp.conf file
sudo cp /etc/ntp.conf /etc/ntp.conf.bak

# Configure NTP servers
echo "server samay1.nic.in iburst" | sudo tee -a /etc/ntp.conf
echo "server samay2.nic.in iburst" | sudo tee -a /etc/ntp.conf

# Restart NTP service
sudo systemctl restart ntp

# Display NTP server status
ntpq -p