In this blog post we’ll setup Azure’s Front Door service and deploy a virtual machine to host a server for basic web traffic. We’ll start with logging into our Azure account and then spinning up a machine, followed by general configuration of the environment. Next, we’ll deploy the Front Door service and test it out. There are bonus objectives for you to explore as well should you be so inclined to do so.
In order for you to be successful in this endeavor, you will need to have a fully functional Microsoft Azure cloud account. In addition, not much else… Just a quality browser (Firefox or Chrome) and the ability to make changes to your Azure account.
If you don’t already have an Azure account, a valid/working credit card is needed to get started – and this is outside of the scope of this blog post. So go take care of that if you need to, and then come back and continue.
The only other thing you will need is going to be an SSH client – we can use a browser plugin to provide this access for us, but something like your Linux/Mac/Windows terminal (or a tool like Putty), may be easier depending on what you are most comfortable with. We’ll deal with they when the time comes.
One last thing before we get started, and that is the level of difficulty you can expect. This is meant for those with a beginner skill set and should be able to be accomplished in about 30-45 minutes.
Let’s get started!
Objective: Login to Azure, and setup your Virtual Machine
To begin, login to your Azure account. You will need to have a sufficiently privileged account as to create and launch a virtual machine (VM). You can go to this link and login: https://azure.microsoft.com/en-us/
Once you login, go to your portal: https://portal.azure.com/#home
Then, navigate to the Virtual machines section and choose “Virtual machines”:
Click the “Add” button and proceed to setup your new VM. You will need to create a new resource group and give the VM a name as well as an image type. The names you choose are arbitrary, but the CentOS image is important as we will use the Linux machine as part of the lab later on. Read what a “Spot Instance” is and note that you do not need to choose this if you don’t want to, and in fact, you may not be able to depending on the other choices made during the setup of the VM.
There is no need to use anything but the cheapest possible VM at this point, so choose accordingly:
Setting the username and password is extremely important. Make sure whatever you create here, you will remember. For a bonus challenge, setup an SSH key and use that for authentication (if you have time at the end of the lab and want to go back).
Be sure to allow ports 80, 443 and 22 so we can SSH into the machine and setup the webserver that our Front Door will point to later.
The hard drive type is not of critical importance for this lab and the defaults can be selected.
Clicking next, we are shown the networking section. Be sure, once again, that ports 80, 22 and 443 are all allowed. The other settings can be left as default.
Going to the next section, the default options are fine here as well and may differ from the screenshot:
Proceed to “Review and Create”
Your current settings should pass validation. If you have any issues, try to identify and fix the problem(s) by reading the output from Azure as it pertains to why your validation failed. Proceed to complete the deployment/creation of your VM and click on “Go to resource” once the process is finished.
From the VM section in the Azure portal, we can see details about our newly created VM:
Look carefully at the “Public IP address”:
Your IP address will be different, make note of it - seriously.
Next, we will SSH into the newly created VM by using an SSH client (putty [you can search for the latest version for your operating system and proceed to install if you choose to] is a great option, as is your CLI for Windows, Linux and Mac) or this browser-based option if you desire:
NOTE: IF YOU PREFER TO USE A DIFFERENT SSH CLIENT, SKIP THIS CHROME EXTENSION SECTION AND SSH INTO YOUR VM AS YOU PREFER
Using Chrome, browser here:
https://chrome.google.com/webstore/detail/secure-shell-app/pnhechapfaindjhompbnflcldabbghjo?hl=en
Install the app:
Then Launch the app by clicking the button to Launch it if you are not automatedly directed to:
chrome://apps/
Click the icon to open it and put in your username (that you created as part of the VM creation process) and the IP address you took a note of a moment ago:
On the bottom-right, select Enter/Connect (and remember to use YOUR OWN IP address and your own username/password combination that you created previously).
Finally, put in your password that you created as part of the VM creation process. Ignore the warning… you should now be successfully logged into your server.
Once logged in successfully, we will install Apache:
Issue the command: sudo su - (and press enter)
Then issue the command: dnf -y install httpd && systemctl start httpd (and press enter)
With these commands, you have changed to the root account (which is required in order to be able to install software), and you have installed the httpd server (which is Apache) and turned it on. Now, to test, open a new tab in your browser and browse to your IP address, you should see the test page showing:
You have completed the first phase. Now we will move onto setting up our Front Door service. You can logout of the SSH session by closing the tab, or by typing exit (twice) in the terminal.
Moving on… Deploy Front Door
With our VM now running successfully, we can leverage the Front Door service to provide access in a more robust way. Within your Azure portal, from within your browser, find the Front Door service icon and click it.
Click the “New” button to start the process of creating a new Front Door:
You will likely only have one subscription option and one Resource Group to choose – so select what is available. Remember, we created our resource group in the first section of this lab when we setup our VM. Click next to continue.
In the configuration section, choose the plus sign for the Frontends/domains box as shown above. Provide a hostname of your choosing and understand that this is like your domain name. Note the .azurefd.net domain associated with the host you are providing. This will be the URL for the outside world to connect to our host once we complete the setup.
As a bonus challenge, once finished with the entire lab, go back and enable the Web Application Firewall and configure it with custom rules. But for now, proceed to the next step.
Click the plus sign to setup the backend pools. What we are doing in this step is telling the Front Door service what or application server is, so when someone goes to access our website through the Front Door, the service knows what application is being hosted. Be sure to input the IP ADDRESS FOR YOUR VM in the corresponding box. If you don’t know what that IP address is, go back to the first part of this blog and take a note.
Next, we’ll add an arbitrarily named back-end pool associated with the host we created and leave the default health probes enabled.
Continuing on, well setup the last part of the service via the routing options:
We’ll add a rule so when traffic comes in, it is directed as we desire:
We’ll choose next and finish up the Front Door setup.
Nice work! Now let’s test it out.
Choose to “Go to resource” and see if you can access your website through the Front Door service.
You may get an error:
Manually change the URL to http instead of https:
If all worked as expected, you should see the Apache test page (note that you may need to wait 10-15 minutes for the process to complete). What now? This was a primer, feel free to go back and setup the Web Application Firewall, install an SSL certificate, deploy custom routing rules, and use a custom domain if you already own one. One thing to note is that you VM is very underpowered (which is fine for testing purposes) but it can be extremely slow as well. You may want to turn off Apache to save resources. systemctl stop httpd
Conclusion
This concludes the blog post. You have learned how to setup a VM and Front Door service in Azure. You used SSH for remote access, you created a frontend host, a backend pool, you have default health-checks running and a functioning test website. Hopefully you enjoyed your time and learned something useful; nice work!
About the Author
When it comes to web application security and penetration testing, Serge is among the best possible instructors to learn from due to his experience, accomplishments, and, quite frankly, his personality. Duplicate badges to walk right through security and access a "secure" facility – did that. Dumpster diving for sensitive information outside of a financial institution – to him, that was “lots of fun.” Create an enterprise-wide, measurably successful security program for a billion-dollar company – one of his many accomplishments. All of them, in scope of the engagements. He’s a published author, President of the Denver Open Web Application Security Project (OWASP) chapter, founder and CEO of the cyber security consulting firm, SpyderSec, he’s discovered multiple 0-days, written OSINT tools for the community, and is a polished presenter who speaks regularly at national conferences. Truly, an expert in the field. Learn more about Serge here.
