To achieve this level of security we will again look at our network diagram and realize that we can communicate on the private network interface rather than the public interface that is facing the public internet. What we want to do is change the network configuration on instance 1 to only listen for traffic from instance 2 and have instance 2 open to the public internet. We will do this with an Apache Web Server because it is easy to configure and test.
Step 1:Go through the configuration steps (all 9 of them) from yesterday and configure one compute instance with an httpd server, ports open, and firewall disabled. We are going to fix the security issues in the upcoming steps and make them only accessible from the second instance that we are about to spin up.
Step 2:Create a second Oracle Linux instance on the same compute cloud. This is done by going into the Create Instance, selecting Oracle Linux 6.6 and accepting the default configurations. A few minutes later we should have a second Linux instance that we can play with. Note that we could have cheated by creating a snapshot of our first instance and spinning up a new instance based on the first instance. This would save us a few steps and configuration options if our installation were more complex. We will save that for another day. Today we will provision an Oracle Linux 6.6 instance with WebServer as the security list which opens up port 80 and 22 for the instance. We accept all of the other defaults.
Step 3:Log into our instance as opc by getting the public ip address from the compute console and using ssh on a Mac or putty on Windows. Once we log in we install w get as a package so that we can read web pages from WebServer1.
Step 4:We can now read the web page from WebServer1 by getting the index.html page from the public ip address as well as the private ip address. We find these ip addresses from the compute console.
Step 5:Now that we can read from the private ip address, we can turn off the public ip address from WebServer1 and communicate on the 10.196 network. This is done by changing the Security List from WebServer back to default for WebServer1. We add the default in the security list and remove the WebServer in the security list.
Step 6:We can test the interface by repeating the read from the http server. We will get a timeout on the public ip address and timeout on the private ip address as well. We will need to create a new security list that allows network communications from the 10.196 network on port 80 to get to the server.
Step 7:We need to define a new Security List that allows port 80 on network 10.196. This is done by going to the Network tab on the compute console and defining a new security list. We will call it privateHttp. Once we have this defined we will allow http on port 80 on the private network but not the public network. We create a security rule for privateWebServer that allows us to go from an instance using port 80 to local instances. Once we have this defined we need to add the privateHttp in the security list for the WebServer1 instance.
Step 7a - add privateHttp to security list
Step 7b - add privateWebServer to security rule
Step 7c - associate new security list with instance
Step 8:Verify that we have connectivity on private network but lack of connectivity on public network
In summary, we created a new compute instance and reconfigured the network for our two compute instances. The goal was to setup our WebServer2 instance so that we could server the public internet with an Apache Web Server. Note that we did not go through these steps because we did this yesterday. We wanted to have WebServer2 talk to WebServer1 but do it on the private network and not have WebServer1 accessible from the public internet. We used an Apache Web Server as the example because it is easy to configure. We could have made this an identity server, a database, a file server, or any service that we want. The key difference would be the port that we create for the communication and security rule/list. Think of running EBusiness Suite or JD Edwards. We really don't want port 1521 of our database exposed to the public internet but we do want the http server exposed. If we run the ERP database on a separate server we need a secure way of communicating with our WebLogic server that is running the ERP logic without exposing drivers license numbers, credit cards, or private information to the public cloud. Hopefully this example allows you to take this concept with web servers and deploy more complex systems into the public cloud securely. It is important to note that we didn't fix the iptables issue and have the firewall turned off for the Linux instance on WebServer1. This is not best practice but we will leave that for another day.