In this second blog, we will discuss how to implement an SSH bastion host that will be the only gateway to access the AWS instances we configured for XVWA. We will also check the validity of our configuration using our deployer configured in Jenkins before the deployment.
We will revisit the set-up we introduced in the first blog of this series. Figure 1 below shows the updated architecture of the application with added security measures. The architecture is improved to add an SSH Bastion Host (6) to make sure that web server (3) is inaccessible by the clients (1) over any ports other than 80 and 8080.
To maintain and update the application the admin (5) now has to access the Bastion Host (6) and then initiate the connection to the webserver (3) on port 22. The Bastion Host (6) is also whitelisted to access the database (4) thus making the setup to update the database (4) accordingly without disrupting the webserver.
A bastion host is a server whose purpose is to provide access to a private network from an external network, such as the Internet. Because of its exposure to potential attack, a bastion host must minimize the chances of penetration. For example, you can use a bastion host to mitigate the risk of allowing SSH connections from an external network to the Linux instances launched in a private subnet of your Amazon Virtual Private Cloud (VPC).
Steps 1-3 show the minimal configuration for the bastion machine and update the webserver security group with new inbound rules. Step 4-5 show the failed case of SSH-ing into the webserver via the internet and how to fix it by SSH-ing via the bastion host. In steps 6-7, we scan the bastion host with Mozilla ssh-scan and analyse the results. For issues identified during the ssh scan, we show the fixes in step 8 and finally, the ssh-scan is successful in step 9.
Step 1: Create an SSH Bastion Host machine with configurations:
- OS: Amazon Linux
- Subnet: public subnet
- Public IP: Yes
Step 2: Create a Security Group for bastion with values:
- Security Group Name: bastion
- Description: bastion security group
- VPC: Choose the VPC created earlier
- Inbound rules:
- Type SSH, Source 0.0.0.0/0
Step 3: Edit the Security Group for the web server
- Remove Inbound rules:
- Type SSH, Source 0.0.0.0/0
- Add Inbound rules:
- Type SSH, Source The identifier of the bastion SG
Step 4: Test the access by ssh-ing into the web server, will fail
Step 5: SSH into bastion then SSH into the webserver, will succeed
Step 6: To harden the SSH Bastion machine, we’ll use Mozilla ssh scan (GitHub – mozilla/ssh_scan)
Step 7: Scan the bastion host machine, will fail, as the SSH configuration on the machine is not hardened to follow best practices. The scanner shows recommendations to remove weak key exchange algorithms, ciphers, MAC algorithms, auth methods as well as suggestions on what algorithms can be added for better security also.
Step 8: Edit and add the recommended algorithm to the sshd_config file in /etc/ssh/
Step 9: Initiate the scan again and this time the scan Succeeds.