To review, we can configure ports into and out of a server by defining a Security Rule and Security List. The options that we have are to allow ports to communicate between the public-internet, sites, or instances. You can find out more about Security Lists from the online documentation. You must have the Compute_Operations role to be able to define a new Security List. With a Security List you can drop inbound packets without acknowledge or reject packets with acknowledgement. The recommended configuration is to Drop with no reply. The outbound policy allows you to permit, drop without acknowledgement or reject the packet with acknowledgement. The outbound policy allows you to have your program communicate with the outside world or lock down the instance. By default everything is configured to allow outbound and deny inbound.
Once you have a Security List defined, you create exceptions to the list through Security Rules. You can find out more about Security Rules from the online documentation. You must have the Compute_Operations role to manage Security Rules. With rules you create a name for the rule and either enable or disable communications on a specific port. For example the defaultPublicSSHAccess is setup to allow communications on port 22 with traffic from the public-internet to your instance. This is mapped to the default Security List which allows console and command line login to Linux instances. For our discussion today we are going to create a new Security List that allows local instances to communicate via ssh and disable public access. We will create a Security Rule that creates the routing locally on port 22. We define a port by selecting a Security Application. In this example we want to allow ssh which corresponds to port 22. We additionally need to define the source and destination. We have the choice of connecting to a Security List or to Security IP List. The Security IP List is either to or from an instance, the pubilc internet, or a site. We can add other options using the Security IP List tab on the left side of the screen. If we look at the default definitions we see that instance is mapped to the instances that have been allocated into this administrative domain (AD). In our example this maps to 10.196.96.0/19, 10.2.0.0/26, 10.196.128.0/19 because these three private ip address ranges can be provisioned into our AD. The public internet is mapped to 0.0.0.0/0. The site is mapped to 10.110.239.128/26, 10.110.239.0/26, 10.110.239.192/26. Note that the netmask is the key difference between the site and instance definitions.
Our exercise for today is to take our WebServer1 (or Instance 1 in the diagram below) and disable ssh access from the public internet. We also want to enable ssh from WebServer2 (or Instance 2) so that we can access the console and shell on this computer. We effectively want to hide WebServer1 from all public internet access and only allow proxy login to this server from WebServer2. The network topology will look like
Step 1:Go through the configuration steps (all 9 of them) from two days ago and configure one compute instance with an httpd server, ports open, and firewall disabled. We will call this instance WebServer1 and go with the default Security List that allows ssh from the public internet.
Step 2:Repeat step 1 and call this instance WebServer2 and go with the default Security List that allows ssh from the public internet.
Step 3:The first thing that we need to do is define a new Security List. For this security list we want to allow ssh on the private network and not on the public network. We will call this list privateSSH.
Step 4:Now we need to define a Security Rule for port 22 and allow communication from the instance to our privateSSH Security List that we just created. We are allowing ssh on port 22 on the 10.x.x.x network but not the public network.
Step 5:We now need to update the instance network options for WebServer1 and add the privateSSH Security List item and remove the default Security List. Before we make this change we have to setup a couple of things. We first copy the ssh keys from our desktop to the ~opc/.ssh directory to allow WebServer2 to ssh into WebServer1. We then test the ssh by logging into WebServer2 then ssh from WebServer2 to WebServer1. We currently can ssh into WebServer1 from our desktop. We can do this as opc just to test connectivity.
Step 6:We add the privateSSH, remove default, and verify the Security List is configured properly for WebServer1.
Step 7:Verify that we can still ssh from WebServer2 to WebServer1 but can not access WebServer1 from our desktop across the public internet. In this example we connect to WebServer1 as opc from our desktop. We then execute step 6 and try to connect again. We expect the second connection to fail.
In summary, we have taken two web servers and hidden one from the public internet. We can log into a shell from the other web server but not from the public internet. We used web servers for this example because they are easy to test and play with. We could do something more complex like deploy PeopleSoft, JDE, E-Business Suite, or Primavera. Removing ssh access is the same and we can open up more ports for database or identity communication between the hidden and exposed services.
The basic answer to the question of "can we hide a server from public internet access" the answer is yes. We can easily hide a server with Security Lists, Security Rules, Security IP Lists, and Security Applications. We can script these in Orchestrations or CLI scripts if we wanted to. In this blog we went through how to do this from the compute console and provided links to additional documentation to learn more about using the compute console to customize this for different applications.