Laying the Azure cloud foundation

Cloud services

We have began the process of laying the foundation for our Hybrid cloud environment on Azure. We have created an Azure subscription for production, development operations, and testing.

The process of migrating mission critical services to Azure cloud is imperative. We have designed, built and deployed virtual resources and machines for our Windows infrastructure.

We will configure all the necessary resources for the Azure virtual network. Azure virtual resource includes: network setting on the virtual machines, such as: Azure virtual networking, public and private IP addressing, subnetting, and firewall configuration.

After configuring the private and public IP for the VM, we will set up virtual network appliance (VNET). In the process of configuring VNET, we determine the appropriate configuration such as: VNET to VNET connectivity. The VNET configuration will connect remote subsets and resources together.

To connect the remote resource. we will create a new virtual gateway to subnet. The VNET actually connects the remote resources together. Once the connections are created, we will assign public and private keys to verify a secure econnection.

One technique to connect remote resources includes creating peer to peer VNETs. We will deploy a VNET gateway to connect remote resources. We will deploy gateway and connections to allow or deny network traffic. The appropriate connections should be associated with the same subscription to function properly.

We will review the process to set up Domain Name Service. We can set up DNS using Azure DNS servers. This configuration supports Azure private zones. Azure private zones allow additional security. Another option is, we can use our internal Windows or Linux DNS servers. This gives us more options to manage our on premise VMs and resources.

Azure provided DNS has several advantages. Such as, no additional configuration needed. The service is ready to go once deployed. Fully qualified DNS names are not required. This provides some simplification of DNS services. Azure is highly available as to reduce any down time. High availability includes redundant backup DNS servers.

Azure provided DNS has some disadvantages. The DNS suffix cannot be changed. WINNS and Netbios are not supported. This must be taken into consideration when deploying Azure DNS servers. Probably not the best solution for internal hybrid environment.

When you implement internal DNS, scavaging service should be turned off. We will configure Azure DNS to facilitate improved name resolution on premise.

For hybrid environments we will implement our own DNS servers with in our domain. This will allow us to connect our Azure virtual machines to our internal on premise servers. This will also allow us to connect Azure virtual machine to multiple networks. This configuration will allow remote, standard, and reverse look up of IP addresses.

To configure Azure DNS we will create a DNS zones. We will assign the zones to the appropriate subscription and subnets. We configure and name the DNS zone based on the domain name and standard naming conventions.

One the DNS zones are created, we will be assigned DNS servers to delegate. In the DNS zone we can get the DNS server information (IP address) for delegation purposes. Typically the domain name is what was purchased from the web register. Example

The next step is adding DNS records to our zone. The 1st record we will add is www which is an A record type. We will leave the TTL set to 1 hour. We can set up C Names records for aliases. We can set up MX records for our email server and any additional services needed.

Since we are setting up DNS for our web server, we will use its physical IP address. Once the A record is created we will test connective by using NSLookup command to find DNS names. The NSLookup command should return the name and IP address of the web server. To create a private DNS zone, you must use Powershell as opposed to the GUI.

To complete the configuration of the network we will setup network security groups. A network security group is comprised of: a list of rules that allow or denies traffic. This applies to virtual machines in subnet, and network interface connected to virtual machine. The rules can be applied to inbound or outbound traffic.

The network security group (NSG) work flow, we can use is traffic is sent to Azure VNET. NSG rules are processed. The VNET determines if Inbound traffic is allowed or denied.

When a virtual machine is provisioned, default security rules are created. By default, inbound VNET traffic is allowed. Inbound traffic to load balances is allowed by default as well The last default rule denies all inbound traffic.

Outbound default rules include: allow outbound VNET traffic, allow outbound web traffic, last rule is to deny outbound traffic.

When establishing security rules they should include source and source port range. We also include destination and destination port range. You can allow all traffic by using an asteric or source port any. You must specify what protocols is to be used. We also need to specify action, allow or deny traffic. additionally we have set a priority to the rule. Rules are processes based on priority. The lowest priority is processed first and the highest last.

A scenario we will deploy is a Smalll network with two subnets. The VNET will deny all traffic except RDP traffic. To accomplish this we will deny all traffic to VNET and associated the two subnets. We will test this scenario by trying to RDP to Virtual machines. (VMS)

To update security rules, we will create a network security group. The NSG has default inbound and outbound security rules established. The NSG is associated a subscription and resource. To create with a security role. We will select inbound or outbound. We will create an inbound NSG rule for RDP. In order for NSG to go into effect, it must be associated with subnet of the VNET. We want to test a deny RDP rule. We’ll select a subnets and associate VM. We will choose both subnet and network interface. To view changes and topology, we can utilize network watcher. We can verify the network and subnet are properly associated, and will route traffic accordingly. Any traffic bound for this network and subnet, are subject to rules with the NSG. We will now associate the Virtual machines network interface. We will edit there security group associated with the network interface. By default the security is the VM itself. Once complete the network interface should be associated with correct security zone. These changes must be done through the network interface due to system constraints.

Many of these tasks can be complete through Powershell. As we complete these tasks. The fist steps is to assign variable such as name, description. Once the NSG is created, we will assign to the appropriate subnet. One of the main commands is get-AZNET. We will create inbound rule to allow access to a web server. The last step is to complete an associating VM with the appropriate subnet. If you ever need to delete a NSG, you must first disassociate it from the subnet.

The next step is to add a rule to NSG to allow access. We’ll select inbound security rules and add. Select a source such as any, IP address or application security group. Then select port address range. Next we’ll specify destination such as NSG, IP address, application security group. Next select port address range. To allow RDP use port 3389. We’ll specify action allow or deny traffic. Then we’ll add priority. This has to have a lower priority then the 500 block all traffic. We’ll give the rule a name. Once the rule is created, we’ll test RDP.

When the network starts to become more complex with multiple NSG, it is important to evaluate effectiveness of your security rules. To help evaluate NSG and rules we will use Network watcher. We will review the effective security rules. We will select the subscription, resource, and the VM. The rules for the resource will be presented. This will include NSG, inbound and outbound rules. Within this configuration we setup NSG for RDP and one for access to web server.

To determine how security rules are affecting a specific VM, go to topology and select the VM. Within the VM select networking. This will show the specific inbound and outbound rules. Review NSG will help determine what traffic is allowed to subnet and then to network interface for the VM.

Within the NSG, we are allowing HTTP to port 80 to the VMs subnet. Local to the VM, the network interface is blocking all inbound traffic. Using effective rules will allow us the manage traffic to our subnets and VMs.

As we deploy a wide range of solutions, we can help improve services, operations, and security. Please contact us for more information!

Author: jbrock

Business owner

Leave a Reply

Your email address will not be published.