Examine Log Files to Block Bad Actors

Lab Overview:

In this lab, you are a Linux security administrator. Using the command prompt, you mimic a password guessing attack on a server. To investigate, you then review the results of your unauthorized access attempts within the server’s log file. Based on the evidence discovered, you then implement a proactive defense by blocking further login attempts by the ‘suspected’ attacker.

Understand the scenario

You are a Linux security administrator. One of your servers was the target of a password guessing attack in which an attacker attempted to log in to the root account. It would be best if you prevented the attackers from gaining access to your server again. First, you will connect to the server, and then you will generate failed login attempts to the server. Next, you will add the IP address belonging to the failed connection attempt to the /etc/hosts.deny file, and then you will verify that a connection attempt from the blocked IP address fails. Finally, you will remove an IP address from the /etc/hosts.deny file.

Connect to Ubuntu2 by using SSH:

This section steps you through the process of successfully establishing an SSH connection to a remote Linux server as the root user. It demonstrates that there are no active defenses, preventing connection to the server. You will learn the basic syntax for using SSH.

Create failed auth.log entries:

In this section, you will intentionally use the wrong password, several times, to attempt logging into a Linux server via SSH. This activity will mimic the behavior of an attacker attempting a password guessing attack against the server. Each password guessing attempt will create an entry in the authentication log file (auth.log) on the server.

Check the auth.log file on Ubuntu2 for failed entries:

After several failed attempts to log into the server, you will then review the server’s authentication log file (auth.log) to investigate the evidence of the password guessing attack. You will learn the location of and command syntax for reviewing the auth.log file. In the log file, you will see evidence of successful and unsuccessful SSH access attempts. The evidence includes the ‘attacker’s’ IP address and user name. This insight will be used to implement a proactive defense, to prevent further unauthorized access attempts.

Prevent connections from Ubuntu1:

In this section, you will implement protection from an attacker by modifying the host access control file (hosts.deny) on the server. The /etc/hosts.deny file allows an administrator to explicitly deny access to the server by specific IP addresses or domain names. In this scenario, you will create an entry for the attacker’s IP address and block access via all protocols.

Allow Ubuntu1 to connect to Ubuntu2:

The task in this section teaches you how to remove a previously blocked IP address entry from the access control file (hosts.deny) on the server. You will learn the command syntax (using cat, sed, and mv commands) to restore the access control file. This is an essential step to restore access to the server if later the access attempts are realized to have been legitimate or the block is no longer deemed required.

Lab Summary Conclusion:

Protecting a server from unauthorized access attempts is a common defensive tactic for a security administrator. This exercise teaches you which log file to examine for authorized and unauthorized access attempts, what evidence to look for to determine if an attacker is trying to guess your password, and what steps to take to proactively block an attacker from gaining unauthorized access to your Linux server. The high-level tasks that you will perform are:

• Verify connectivity between two hosts.
• Create an /etc/hosts.deny entry on a host that you want to protect.
• Test connectivity to confirm denied host.
• Remove the /etc/hosts.deny entry to restore connectivity.

Other Challenges in this series:

• GUIDED CHALLENGE: Harden a Server by Limiting Access to a Single Subnet
• ADVANCED CHALLENGE: Can You Harden a Server by Restricting Access per Protocol?