In: Computer Science
You are creating a Security Group for a group of mission-critical EC2 instances, and do not want to allow just anyone to be able to SSH into them. As such, you cannot allow traffic on port 22 from the open Internet. What best practice can you implement to still allow you and your colleagues to be able to establish an SSH connection with these instances, without allowing anyone with Internet access to do the same?
Group of answer choices
Deploy another EC2 instance as a "bastion host." Allow only the bastion host instance SSH access to the sensitive EC2 instances. Then, cleared employees can securely log in to the bastion host before jumping into another SSH connection to the target EC2 instances.
Configure the Security Groups on the sensitive EC2 instances to only allow SSH traffic from the IP addresses that belong to you and your colleagues.
Disable SSH access, and use Telnet instead.
Change the SSH configuration on the sensitive EC2 instances to listen on a harder-to-guess port, such as 22521.
Out of the given options, #1 is the best practice. Deploy another EC2 instance as a "bastion host." Allow only the bastion host instance SSH access to the sensitive EC2 instances. Then, cleared employees can securely log in to the bastion host before jumping into another SSH connection to the target EC2 instances.
This is so because deploying the Bastion Host adds an extra layer of security to our architecture. The attacker won't be able to access the private instances directly. The bastion host will act as a proxy server or a jump box. Even if it gets compromised, it is difficult to reach the private instance.
Second option: Configure the Security Groups on the sensitive EC2 instances to only allow SSH traffic from the IP addresses that belong to you and your colleagues. This is also another way to allow limited access but if the hacker can spoof IP address, our instance will directly be compromised. We will have limited response time. Whereas, if the bastion host is compromised, we will still have time to protect the mission-critical instance.
Third option: Disable SSH access and use Telnet instead. This is the least secure way because the Telnet protocol has less security features than the SSH. Telnet sends the data in plain text without encryption whereas SSH first encrypts the data.
Fourth Option: Change the SSH configuration on the sensitive EC2 instances to listen on a harder-to-guess port, such as 22521. This option is also not secure because we are directly exposing our sensitive instance. The hacker might easily be able to figure out the new port number via brute force or some other technique.