Harden a Server by Limiting Access to a Single Subnet
In this IT Pro Challenge virtual lab, you will get hands-on experience hardening an Ubuntu Linux server by managing the /etc/hosts.deny and /etc/hosts.allow configuration files. As a security-minded administrator, it is best practice to permit access only to systems and services that are required. These skills are essential for a Linux administrato...
This hands-on lab provides a Linux administrator with a basic understanding of how to manage remote access to ports and services on a Linux server, by restricting access using the /etc/hosts.deny configuration file and/or by permitting access using the /etc/hosts.allow configuration file. These are fundamental security skills that will help a Linux administrator secure their environment.
Understand the scenario
You are a Linux system administrator, and you will use two Ubuntu Linux virtual machines for this challenge. You need to restrict access by explicitly permitting only employees from the IT department subnet to access the server via SSH. First, you will verify that you can connect to the server using SSH. Then, you will modify the /etc/hosts.deny and the /etc/hosts.allow files to accept only SSH connections from a specific subnet, and then you will verify that you are now unable to connect (as your source system is on a different subnet). Finally, you will modify the block by changing to the correct subnet, and then you will verify that you are now able to connect to the target server from the appropriate host.
Connect to Ubuntu2 by using SSH:
In the first part of this lesson, you will validate that the Linux virtual machine lab environment is configured to permit your two systems to communicate with each other over SSH. This step will have you log in to a remote system using SSH – confirming that the service is not blocked.
Edit the /etc/hosts.deny file:
For this task, you will switch to the target server and modify the /etc/hosts.deny configuration file by adding a line that reads “ALL: ALL.” This deny rule causes the server to refuse all connection attempts to running daemons on the host. You will confirm that the rule is effective, by switching back to the source system and again trying to connect over SSH.
Edit the /etc/hosts.allow file:
Having a restrictive deny rule like “ALL: ALL” in your configuration file is best practice. You will then use the /etc/hosts.allow configuration file to explicitly permit a specified subnet to connect to only the SSH service on the target server. Once again, you will switch to the source system and confirm whether the rule is effective. (Note: pay attention to your source system IP address and the subnet that was permitted. Could you access the service?)
Allow SSH connections from 192.168.10.0:
In this section, you will change the subnet that is permitted to access the SSH service on your server. Although this lab gives you hints on how to make this change, pay close attention to the command and syntax that are used. This task displays how the sed command can replace contents of a file with new content. In this case, the command will change the rule from permitting the 192.168.15.0/24 subnet to permitting the 192.168.10.0/24 subnet.
Lab Summary Conclusion:
In this hands-on virtual lab, you will learn how to manage your /etc/hosts.deny and /etc/hosts.allow configuration files. These skills will be useful in protecting your Linux environment and are basic skills for a Linux administrator or a Penetration Tester.
Other Challenges in this series
- GUIDED CHALLENGE: Force Users to Change Their Password Upon First Sign In
- GUIDED CHALLENGE: Block Bad Actors by Using Log Files