Cybersecurity Audit Process in Linux.

This lab will guide you through the key steps involved in conducting a Cybersecurity Audit on a Linux system, specifically using Kali Linux. As an auditor, your goal is to identify vulnerabilities, assess system configurations, and provide recommendations for strengthening security.

The lab has two parts:

1. Part-1: Manual Auditing
2. Part-2: Automated Auditing using Lynis

Part-1: Manual Auditing

Scenario: Just to be the auditing in context

You’ve been hired as a cybersecurity auditor by a small tech firm that has recently set up its development environment on Kali Linux. The firm is concerned about potential vulnerabilities due to multiple users accessing the system and the open nature of some configurations. Your job is to perform an audit of the Kali Linux system, identify weaknesses, document your findings, and provide actionable recommendations to enhance security.

The firm has shared their concerns specifically about unauthorised access, file integrity, and network security. They would like a report that explains any identified risks, their potential impact, and suggested remediation steps.

Lab Setup

1. Machine Setup:

   • Use the Victim VM provided for this lab.
   • To open the VM: Go to your weekly folder, specifically the "week-8" folder. Locate the VM file, and double-click it to launch. If prompted, select the option to open it in your virtual machine software (such as VirtualBox).
   • Login Credentials (UBUNTU VM):
     • Username: victim
     • Password: victimvm

2. Tools Needed:

   • This lab includes instructions to install any necessary tools. If you're using your own machine and he required tool is missing, simply follow the installation command provided within each task.

   • Ensure you have administrative privileges if you are using your own machine, as some installations will require sudo permissions.

Lab Tasks and Questions

There are 10 different areas of focus. Feel free to go through them all, or pick at least 5 to strengthen your understanding.

1. User and Permissions Audit

• Note: No additional tools are needed for this task.
• Task: Review all users, groups, and permissions for files in the /etc and /home directories.
• Commands:
  • cut -d: -f1 /etc/passwd: List all users.
  • cat /etc/group: List all groups.
  • ls -l /home: Check permissions of home directories.
• Questions:
  1. Are there any users with root privileges that are unnecessary or unexpected? Why is this a potential security risk?
  2. Identify files in /etc that have permissions allowing group or other write access. Why might this be dangerous?
  3. What would be an appropriate action if you found a sensitive file with 777 permissions?

2. System Log Analysis

• Note: No additional tools are needed for this task.
• Task: Review logs in /var/log to identify potential security events, focusing on SSH and system errors.
• Commands:
  • sudo grep "Accepted" /var/log/auth.log: Find successful SSH logins.
  • sudo grep "Failed password" /var/log/auth.log: Find failed SSH login attempts.
  • sudo cat /var/log/syslog | grep -i error: Identify system errors.
• Questions:
  1. How many failed SSH login attempts are in the log? What might a high number of failed attempts indicate?
  2. Can you identified sources of the attempts,e.g., ip address, etc.
  3. Describe any unusual patterns in the logs that could suggest a security issue.

3. Auditing Network Connections

• Note: No additional tools are needed for this task.
• Task: Analyse active network connections and services, checking for any unusual or unnecessary services.
• Commands:
  • netstat -tulnp: List active listening services and associated processes.
  • lsof -i: Check open network sockets.
• Questions:
  1. Which services are actively listening on your system? Are there any you didn't expect?
  2. Identify any services running on unusual ports. Why might this be a concern?

4. System Hardening with auditd

• Note: If you’re using your own machine and auditd is not installed, use sudo apt install auditd to install it.
• Tasks: Use auditd to monitor critical files and generate alerts for changes.

Task 1: Start the auditd Service

1. Check auditd status:

   sudo service auditd status
   

   • Ensure auditd is active. If it’s not running, start the service.

2. Start the service (if needed):

   sudo service auditd start
   

   • Verify that auditd is now active.

Task 2: Add Monitoring Rules for Password and Authentication Logs

1. Set up monitoring for the /etc/passwd file:

   • This file contains user account information. Any changes to it should be audited.

   sudo auditctl -w /etc/passwd -p wa -k passwd_changes
   

   • -w specifies the file to watch, -p wa sets permissions to watch for write and attribute changes, and -k adds a key identifier.

2. Add a rule to monitor /var/log/auth.log:

   • This log file tracks authentication events and is essential for security monitoring.

   sudo auditctl -w /var/log/auth.log -p r -k auth_attempts
   

3. Confirm the Rules:

   • List the active rules to verify they were added correctly.

   sudo auditctl -l
   

Task 3: Change the Password to Trigger an Event

1. Change the password for the admin account (or another test account):

   sudo passwd
   

   • Follow the prompts to enter a new password. This action should trigger auditd to log changes in /etc/passwd as well as possible entries in /var/log/auth.log.

2. Generate additional events (optional):

   • Attempt a login or use other commands that interact with /etc/passwd or /var/log/auth.log to create more audit entries.

Task 4: View and Interpret the Audit Logs

1. View passwd_changes logs:

   • Use ausearch to retrieve logs specific to changes in /etc/passwd.

   sudo ausearch -k passwd_changes
   

   • Observe the log entries showing who made the change, the time, and what action was performed.

2. View auth_attempts logs: (you should be able to see something simlar to Taks-1 above viewing /var/log/)

   • Retrieve logs specific to /var/log/auth.log to see authentication-related entries.

   sudo ausearch -k auth_attempts
   

3. Interpret Log Entries:

   • Each entry provides detailed information, including user ID, date, time, and type of action. Review these details to understand the type of access or modification attempted.

Removing auditd Rules

To remove an auditd rule, follow these steps:

• First let's veiw all rules using:

  sudo auditctl -l
  

• Remove a Specific Rule by File or Key

  • If you want to delete a rule associated with a specific file, use the same command to remove it but with the -W flag:

    sudo auditctl -W /etc/passwd -p wa -k passwd_changes
    

• Or you can remove all rules at once:

  sudo auditctl -D
  

5. Firewall Rules with iptables

• Note: No additional tools are needed for this task.
• Task: Review and set up basic firewall rules using iptables.

1. List Current Rules:

   • Begin by reviewing the current iptables rules to understand the initial security configuration:

     sudo iptables -L
     

   • This will display any pre-existing rules. Make a note of these before adding new rules.

Step-by-Step Guide to Manage SSH Rules with iptables

Step 1: Add a Rule to Allow SSH Traffic

First, add a rule to allow SSH (port 22) traffic so that you can test initial access.

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

• -A INPUT: Appends the rule to the INPUT chain.
• -p tcp --dport 22: Specifies the protocol (tcp) and port (22 for SSH).
• -j ACCEPT: Allows SSH traffic.

Step 2: Test the SSH Allow Rule (we will do it togather)

From another machine on the same network (using admin (csf_vm1 vm, password: kalivm1) machine from previos weeks, but make sure they are connected to the same NAT), attempt to SSH into the server to confirm that the SSH ACCEPT rule is working:

ssh username@<server-ip-address>

If the connection is successful, this verifies that SSH traffic is being allowed.

Step 3: Remove the SSH Allow Rule

After verifying SSH access, remove the rule to stop allowing SSH traffic.

1. List Rules with Line Numbers:

   sudo iptables -L INPUT --line-numbers
   

   • Note the line number of the SSH ACCEPT rule.

2. Delete the Rule by Line Number:

   Assuming the SSH ACCEPT rule is on line 1, delete it with:

   sudo iptables -D INPUT 1
   

   Adjust the line number as needed based on your listing.

Step 4: Add a Rule to Block SSH Traffic

Now, add a rule to block SSH traffic explicitly:

sudo iptables -A INPUT -p tcp --dport 22 -j DROP

• -j DROP: Drops all SSH traffic, effectively blocking access to port 22.

Step 5: Test the SSH Block Rule

From the other machine, try to SSH into the server again:

ssh username@<server-ip-address>

The connection should now be blocked, verifying that the DROP rule for SSH is functioning as expected.

This process provides hands-on practice with iptables for adding, testing, removing, and blocking SSH rules.

Discussion Questions (Something to think about)

1. Describe the purpose of the firewall rule you added. How does it contribute to system security?

   • Explain the importance of restricting traffic to only necessary services, reducing the attack surface.

2. What risks might arise if SSH access is left open to all IP addresses?

   • Discuss the security implications of open SSH access, including the risk of brute-force attacks.

3. Explain the difference between an "allowlist" (permissive) approach and a "denylist" (restrictive) approach in firewall configurations.

   • Compare the advantages of an "allowlist" (default deny) approach, which blocks everything by default, versus a "denylist" (default allow), which may leave room for unknown vulnerabilities.

6. Software and Package Auditing

• Note: No additional tools are needed for this task.
• Task: Identify outdated software and remove any unnecessary packages.
• Commands:
  • List all installed packages: dpkg -l.
  • Check for available updates: sudo apt list --upgradable.
• Questions: (Think of PSTI from Week-2)
  1. Why is it crucial to keep software up-to-date in a cybersecurity-focused system?
  2. Identify two installed packages you think might be unnecessary. What criteria would you use to decide whether to remove a package?
  3. How can auditing installed packages help in preventing vulnerabilities?

7. SSH Configuration Audit

• Note: No additional tools are needed for this task.
• Task: Audit and secure SSH configuration.
• Commands:
  • Open SSH configuration: sudo nano /etc/ssh/sshd_config.
  • Set PermitRootLogin no and PasswordAuthentication no.

SSH Configuration Settings Audit Table

• Questions:
  1. What is the impact of disabling root login for SSH? How does this improve security?
  2. Explain why it is recommended to disable password authentication for SSH.
  3. Suggest two other SSH configuration settings that enhance security.

Part-2: Automated Auditing using Lynis

Use Lynis to perform a basic security audit on a Linux system, identify potential security issues, and understand how to interpret the audit results.

Note: If Lynis is not installed, you can install it by running

Internet connection is required here:

sudo apt install lynis

Lab Steps

Please use the same VM from Part-1.

1. Perform a System Audit

1. Run Lynis in System Audit Mode: Start a full system audit with the following command:

   sudo lynis audit system
   

2. Observe the Audit Process:
   • Lynis will examine various security areas, such as authentication, firewall settings, file integrity, and kernel configurations.
   • Take note of any warnings or suggestions displayed during the scan.

2. Review the Audit Results

1. Check the Summary:

   • At the end of the audit, review the summary provided by Lynis, which includes warnings (potential security risks) and suggestions (recommended best practices).
   • Note the system hardening score, which gives an overall indication of the system’s current security level.

2. View the Detailed Report:

   • A more comprehensive report is stored in /var/log/lynis-report.dat.
   • Use cat or less to view the file:

    sudo less /var/log/lynis-report.dat
   

   Or

   sudo cat /var/log/lynis-report.dat
   

IMPORTANT(FYI): Exporting Command Output to a Text File in Linux

To export the results of any command into a text file in Linux, you can use output redirection with >. Here’s a quick guide:

1. Exporting Output of a Simple Command

To save the output of a simple command, such as listing files in a directory (ls), to a text file:

ls > dir_test.txt

This saves the list of files in the current directory to dir_test.txt. You can open this file with any text editor or view it with:

cat dir_test.txt

2. Exporting Results of a Lynis Audit

To export the results of a Lynis system audit to a text file:

sudo lynis audit system > lynis_audit_results.txt

This command saves the Lynis audit output into lynis_audit_results.txt.

• Appending to a File: If you want to add results to an existing file without overwriting it, use >> instead:

  sudo lynis audit system >> lynis_audit_results.txt
  

• Checking the Output: View the results by opening the file:

  cat lynis_audit_results.txt
  

These steps allow you to save output from both simple commands and Lynis audits into text files for easy review and record-keeping.

3. Discussion: Firewall Recommendations

This section covers one common topic from the Lynis report which is firewall settings

Firewall Settings

Lynis may flag the absence of a firewall or suggest reviewing firewall rules to ensure only necessary ports are open.

• Example Warning:
  • "No active firewall detected", or "Unrestricted access on port 80".
• Suggested Remediation:
  • Enable the firewall and allow only specific services. For example:

    sudo ufw enable
    sudo ufw allow 22   # Allow SSH
    sudo ufw allow 80   # Allow HTTP if running a web server
    

  • List all firewall rules to verify:

    sudo ufw status
    

• Security Impact:
  • Restricting open ports reduces the attack surface by limiting network access to essential services, helping prevent unauthorised access.

4. Analyse the Findings

Answer the following questions based on Lynis’s audit results:

Questions

1. What is the system hardening score, and what does it suggest about your system’s security level?

   • Hint: Look for the score in the summary section.

2. Identify three warnings from the audit. Why might they be a security concern?

3. List three recommendations provided by Lynis and how you would implement them.

   • Example: Lynis might recommend enabling automatic updates or improving SSH configurations.

5. Apply Remediation Steps (Ideally): Optional

To improve your security score, choose at least one warning or suggestion from the audit and implement the recommended change:

1. Research how to resolve the identified issue and apply the necessary configuration changes.
2. Re-run Lynis with sudo lynis audit system to see if the change positively impacted the security score.

More reading

• Cyber assessment framework (CAF)
• Cyber Resilience Audit scheme
  • Cyber Resilience Audit Scheme Standard