I recently was tasked with deploying two Fortinet FortiGate firewalls in Azure in a highly available active/active model. I quickly discovered that there is currently only two deployment types available in the Azure marketplace, a single VM deployment and a high availability deployment (which is an active/passive model and wasn’t what I was after).
To achieve an active/active model you must deploy two separate FortiGate’s using the single VM deployment option and then deploy the Azure load balancers separately. I will not be going through how to deploy the FortiGate’s and required VNets, subnets, route tables, etc. as that information can be found here on Fortinet’s support site: http://cookbook.fortinet.com/deploying-fortigate-azure/. NOTE: When deploying each FortiGate ensure they are deployed into different frontend and backend subnets, otherwise the route tables will end up routing all traffic to one FortiGate. Once you have two FortiGate’s, a public load balancer and an internal load balancer deployed in Azure you are ready to configure the FortiGate’s.
NOTE: Before proceeding ensure you have configured static routes for all your Azure subnets on each FortiGate otherwise the FortiGate’s will not be able to route Azure traffic correctly.
To direct all internet traffic from Azure via the FortiGate’s will require some configuration on the Azure internal load balancer and a user defined route.
Create a load balance rule with:
Backend Port: 443
Health probe: Health probe port (e.g. port 22)
Session Persistence: Client IP
Floating IP: Enabled
Repeat step 1 for port 80 and any other ports you require
Create an Azure route table with a default route to the Azure internal load balancer IP address
Assign the route table to the required Azure subnets
IMPORTANT: In order for the load balance rules to work you must add a static route on each FortiGate for IP address: 18.104.22.168. This is required for the Azure health probe to communicate with the FortiGate’s and perform health checks.
Once complete the outbound internet traffic flow will be as follows:
To publish something like a web server to the internet using the FortiGate’s will require some configuration on the Azure public load balancer. Let’s say I have a web server that resides on my Azure DMZ subnet that hosts a simple website on HTTPS/443. For this example the web server has IP address: 22.214.171.124.
Add an additional public IP address to the Azure public load balancer (for this example let’s say the public IP address is: 126.96.36.199)
Create a load balance rule with:
Frontend IP address: 188.8.131.52
Backend Port: 443
Session Persistence: Client IP
On each FortiGate create a VIP address with:
External IP Address: 184.108.40.206
Mapped IP Address: 220.127.116.11
Port Forwarding: Enabled
External Port: 443
Mapped Port: 443
You can now create a policy on each FortiGate to allow HTTPS to the VIP you just created, HTTPS traffic will then be allowed to your web server. For details on how to create policies/VIPs on FortiGate’s refer to the Fortinet support website: http://cookbook.fortinet.com. Once complete the traffic flow to the web server will be as follows:
I have a complex customer environment where Microsoft Identity Manager is managing identities across three Active Directory Forests. The Forests all serve different purposes and are contained in different network zones. Accordingly there are firewalls between the zone where the MIM Sync Server is located and two of the other AD Forests as shown in the graphic below.
As part of the project the maintainers of the network infrastructure had implemented rules to allow the MIM Sync server to connect to the other two AD Forests. I had successfully been able to create the Active Directory Management Agents for each of the Forests and perform synchronization imports.
The Error ‘kerberos-no-logon-server’
Everything was going well right up to the point I went to export changes to the two AD Forests that were separated by firewalls. I received the ‘kerberos-no-logon-server’ error as shown below from the run profile output.
I started investigating the error as I hadn’t encountered this one before. There were a few posts on the possibilities mainly dealing with properties of the AD MA’s configuration. But I did stumble on a mention of kerberos being used when provisioning users to Active Directory and setting the initial password. That aligned with what I was doing. I had provided the networking engineers with my firewall port requirements. Those are (no PCNS required for this implementation) ;
389 TCP – LDAP
636 TCP – LDAPS
88 TCP – Kerberos
464 TCP/UDP – Kerberos
53 TCP – DNS
3268 TCP/UDP – Global Catalog
3269 TCP/UDP – Global Catalog
135 TCP – RPC
My old school immediate thought was to Telnet to each of the ports to see if the firewall was allowing me through. But with a couple of forests to test against and UDP ports as well, it wasn’t going to be that easy. I found a nice little Test-Port function that did both TCP and UDP. I already had an older script for testing TCP ports via PowerShell. So I combined them.
Identifying the cause
As suspected connectivity to the forest where my MIM Sync Server was located was all good. The other two, not so much. GC connectivity wouldn’t give me the Kerberos error, but not having Kerberos Port 464 certainly would.
In the backwards and forwards with the networking team I had to test connectivity many times so I added a running output as well as a summary output. The running output highlighting ports that weren’t accessible.
Here’s the raw script if you’re in a similar situation. Get the Test-Port Function from the URL in line 1 to test UDP Port connectivity. Add additional ports to the arrays if required (eg. for PCNS), and update the forest names in lines 21-23.
I’m sure this is going to become more relevant in a Cloud/Hybrid world where MIM Servers will be in Azure, Active Directory Forests will be in different networks and separated by firewalls and Network Security Groups.
In the real world there are numerous lessons learned, experiences, opinions and vendors recommendations that dictate and what constitutes “best practice” when it comes to internet edge security. It’s a can of worms that I don’t want to open as I am not claiming to be an expert in that regard. I can say that I do have enough experience to know that not having any security is a really bad idea and having bank level security for regular enterprise customers can be excessive.
I’ve been working with an enterprise customer that falls pretty much in the middle of that dichotomy. They are a regular large enterprise organisation that is concerned about internet security and have little experience with Azure. That said, the built in tools and software defined networking principles of Azure don’t meet the requirements they’ve set. So, to accomodate those requirements, moving from Azure NSGs and WAFs and all the goodness that Azure provides to dedicated virtual appliances was not difficult, but, did require a lot of thinking and working with various team members and 3rd parties to get the result.
Cisco Firepower Thread Defence Virtual for Microsoft Azure
From what I understand, Cisco’s next generation firewall has been in the Azure marketplace for about 4 months now, maybe a little longer. Timelines are not that much of a concern, rather, they are a consideration in that it relates to the maturity of the product. Unlike competitors, there is indeed a lag behind in some features.
The firewalls themselves, Cisco Firepower Thread Defence Virtual for Microsoft Azure, are Azure specific Azure Marketplace available images of the virtual appliances Cisco has made for some time. The background again, not that important. It’s just the foundational knowledge for the following:
Cisco FTDv supports 4 x network interfaces in Azure. These interfaces include:
A management interface (Nic0) – cannot route traffic over this
A diagnostics interface (Nic1) – again, cannot route traffic over this. I found this out the hard way…
An external / untrusted interface (Nic2)
An internal / trusted interface (Nic3)
So we have a firewall that essentially is an upgraded Cisco ASA (Cisco Adaptive Security Appliance) with expanded feature sets unlocked through licensing. An already robust product with new features.
Availability is key in the cloud. Scale out dominates scale up methodologies and as the old maxim goes: two is better than one. For a customer, I put together the following design to leverage Azure availability sets (to guarantee instance uptime of at least one instance in the set; and to guarantee different underlying Azure physical separation of these resources) and to have a level of availability higher than a single instance. NOTE:Cisco FTDv does not support high availability (out of the box) and is not a statefull appliance in Azure.
To deploy a Cisco FTDv in Azure, the quick and easy way is to use the Azure Marketplace and deploy through the portal. It’s a quick and pretty much painless process. To note though, here are some important pieces of information when deploying these virtual appliances from the Azure marketplace:
There is essentially only one deployment option for the size of instances – Standard_D3 or Standard_D3v2 – the difference being SSD vs HDD (with other differences between v1 and v2 series coming by way of more available RAM in certain service plans)
YOU MUST deploy the firewall in a resource group WITH NO OTHER RESOURCES in that group (from the portal > Marketplace)
Each interface MUST be on a SUBNET – so when deploying your VNET, you need to have 4 subnets available
ALSO, each interface MUST be on a UNIQUE subnet – again, 4 subnets, can’t double up – even with the management and diagnostic interfaces
Deploying the instance in an Azure availability set is- NOT AVAILABLE (from the portal > Marketplace)
Going through the wizard is relatively painless and straight forward and within 15-20min you can have a firewall provisioned and ready to connect to your on-premises management server. Yes, another thing to note is that the appliance is managed from Firepower Management Centre (FMC). The FMC, from that I have read, cannot be deployed in Azure at this time. However, i’ve not looked into that tidbit to much, so I may be wrong there.
In my design I have a requirement for two appliances. These appliances would be in a farm, which is supported in the FMC, and the two appliances can have common configuration applied to both devices- stuff like allow/deny rules. In Azure, without an availability set, there is a small chance, however a chance nonetheless, that both devices could someone be automagically provisioned in the same rack, on the same physical server infrastructure in the Australia East region (my local region).
Availability is a rather large requirement and ensuring that all workloads across upwards of 500+ instances for the customer I was working with is maintained was a tricky proposition. Here’s how I worked around the problem at hand as officially Cisco do not state they “do not support availability sets”.
Pretty much all resources when working with the Azure Portal have a very handy tab under their properties. I use this tab a lot. It’s the Automation Script section of the properties blade of a resource.
After I provisioned a single firewall, I reviewed the Automation Script blade of the instance. There is plenty of good information there. What was particularly is handy to know is the following:
So with that, we have all the key information to leverage ARM templates to deploy the firewalls. In practice though, I copied the entire Automation Script 850 line JSON file and put it into Atom. Then I did the following:
Reviewed the JSON file and cleaned it up to match the naming standard for the customer
This applied to various resources that were provisioned: NIC, NSGs, route tables etc
I copied and added to the file an addition for adding the VM to availability set
The code for that will be bellow
I then removed the firewall instance and all of the instance specific resources it created form Azure
I manually removed the NICs
I manually removed the DISKs from Blob storage
I then used Visual Studio to create an ew project
I copied the JSON file into the azuredeploy.json file
Updated my parameters file (azuredeplpy.parameters.json)
Finally, proceeded to deploy from template
Low and behold the firewall instance provisioned just fine and indeed there was an availability set associated with that. Additionally, when I provisioned the second appliance, I followed the same process and both are now in the same availability set. This makes using the Azure Load Balancer nice and easy! Happy days! For your reference, here’s the availability set JSON I added in my file:
Those are really the only things that need to be added to the ARM template. It’s quick and easy!
BUT WAIT, THERES MORE!
No, I’m not talking about throwing in a set of steak knives with that, but, there is a little more to this that you dear reader need to be aware of.
Once you deploy the firewall and the creating process finalises and its state is now running, there is an additional challenge. When deploying via the Marketplace, the firewall enters Advanced User mode and is able to be connected to the FMC. I’m sure you can guess where this is going… When deploying the firewall via an ARM template, the same mode is not entered. You get the following error message:
User [admin] is not allowed to execute /bin/su/ as root on deviceIDhere
After much time digging through Cisco documentation, which I am sorry to say is not up to standard, Cisco TAC were able to help. The following command needs to be run in order to get into the correct mode:
~$ su admin
~$ [password goes here] which is Admin123 (the default admin password, not the password you set)
Once you have entered the correct mode, you can add the device to the FMC with the following:
~$ configure manager add [IP address of FMC] [key - one time use to add the FW, just a single word]
I appreciate that speciality network vendors provide really good quality products to manage network security. Due limitations in the Azure Fabric, not all work 100% as expected. From a purists point of view, NSGs and the Azure provided software defined networking solutions and the wealth of features provided, works amazingly well out of the box.
The cloud is still new to a lot of people. That trust that network admins place in tried and true vendors and products is just not there yet with BSOD Microsoft. In time I feel it will be. For now though, deploying virtual appliances can be a little tricky to work with.
I have been part of the Windows 10 Insider program for some time now, and as usual the time had come around again to install the latest fast ring update 14946. However, when I went to download the update via the usual windows update channel, I found I could not download the update at all. (Or the bar showed zero progress). I started to go looking for an explanation and came across the following post on the Microsoft Forum site. https://social.technet.microsoft.com/Forums/windows/en-US/e984c816-5c21-47f9-8d9d-94dd1d0137de/insider-preview-build-14946-at-fast-ring?forum=win10itprosetup I am running Bitdefender 2016 on my machine so guessed this might be the problem. Now! I didn’t want to leave my machine unprotected, so I thought I would see if I could get the problem fixed.
Run a repair of Bitdefender 2016
Open control panel and launch Programs & Features
Locate Bitdefender 2016 and select Uninstall (This won’t uninstall the product)
Choose the repair option in the popup menu
Restart the computer when prompted
Update Bitdefender once the machine has restarted
Open the Bitdefender control panel from the desktop or taskbar
Open the Firewall module using the modules button on the front panel
Click the gear icon next to the firewall module
Select the adaptors tab
Update the wifi or ethernet connection that is active to the following
Network Type – Trusted or home/office
Stealth Mode – Off
Close the Bitdefender control panel
Note: I needed to toggle the firewall module off/on before I could edit the network adapter configuration. I was running a ping to my local gateway while making changes to the Bitdefender adapter configuration in order to see when the network connection became active. Hope this helps some of you out as well. Shane.
One of the most common methods of attack is The Script Kiddie / Skiddie / Script Bunny / Script Kitty. Script Kiddies attacks frequency is one of the highest frequency and still is. However the attacks have been evolved into something more advanced, sophisticated and far more organized. The diagram below illustrates the evolution of attacks:
The main target of the attacks from the lowest sophistication level of the attacks to the most advanced one is our data. Data loss = financial loss. We are working together and sharing the responsibility with our cloud provider to secure our cloud environment. This blog post will focus on Azure environment.
Defense in Depth
Based on SANS Institute of Information Security. Defense in depth is the concept of protecting a computer network with a layer of defensive mechanisms. There are varies of defensive mechanisms and countermeasures to protect our Azure environment because there are many attack scenarios and attack methods available.
In this post we will use combination of Azure Network Security Groups to establish Security Zone discussed previously on my previous blog, deploy network firewall including Intrusion Prevention System on our Azure network to implement additional high security layer and route the traffic to our security kit. On Secure Azure Network blog we have learned on how to establish the simple Security Zone on our Azure VNET. The underlying concept behind the zone model is the increasing level of trust from outside into the center. On the outside is the Internet – Zero Trust which is where the Script Kiddies and other attackers reside.
The diagram below illustrates the simple scenario we will implement on this post:
There are four main configurations we need to do in order to establish solution as per diagram above:
Azure VNET Configuration
Azure NSG and Security Rules
Azure User Defined Routes and IP Forwarding
Barracuda NG Firewall Configuration
In this post we will focus on the last two items. This tutorial link will assist the readers on how to create Azure VNET and my previous blog post will assist the readers on how to establish Security Zone using Azure NSGs.
Barracuda NG Firewall
The Barracuda NG Firewall fills the functional gaps between cloud infrastructure security and Defense-In-Depth strategy by providing protection where our application and data reside on Azure rather than solely where the connection terminates.
The Barracuda NG Firewall can intercept all Layer 2 through 7 traffic and apply Policy – based controls, authentication, filtering and other capabilities. Just like its physical device, Barracuda NG Firewall running on Azure has traffic management capability and bandwidth optimizations.
The main features:
PAYG – Pay as you go / BYOL – Bring your own license
IDS – IPS
Network Access Control Management
Advanced Threat Detection
Above features are necessary to establish a virtual DMZ in Azure to implement our Defense-In-Depth and Security Zoning strategy.
Choosing the right size of Barracuda NG Firewall will determine the level of support and throughput to our Azure environment. Details of the datasheet can be found here.
I wrote handy little script below to deploy Barracuda NG Firewall Azure VM with two Ethernets :
User Defined Routes in Azure
Azure allows us to re-defined the routing in our VNET which we will use in order to re-direct the routing through our Barracuda NG Firewall. We will enable IP forwarding for the Barracuda NG Firewall virtual appliance and then create and configure the routing table for the backend networks so all traffic is routed through the Barracuda NG Firewall.
There are some notes using Barracuda NG Firewall on Azure:
User-defined routing at the time of writing cannot be used for two Barracuda NG Firewall units in a high availability cluster
After the Azure routing table has been applied, the VMs in the backend networks are only reachable via the NG Firewall. This also means that existing Endpoints allowing direct access no longer work
Step 1: Enable IP Forwarding for Barracuda NG Firewall VM
In order to forward the traffic, we must enable IP forwarding on Primary network interface and other network interfaces (Ethernet 1 and Ethernet 2) on the Barracuda NG Firewall VM.
Enable IP Forwarding:
Enable IP Forwarding on Ethernet 1 and Ethernet 2:
On the Azure networking side, our Azure Barracuda NG Firewall VM is now allowed to forward IP packets.
Step 2: Create Azure Routing Table
By creating a routing table in Azure, we will be able to redirect all Internet outbound connectivity from Mid and Backend subnets of the VNET to the Barracuda NG Firewall VM.
Firstly, create the Azure Routing Table:
Next, we need to add the Route to the Azure Routing Table:
As we can see the next hop IP address for the default route is the IP address of the default network interface of the Barracuda NG Firewall (192.168.0.54). We have extra two network interfaces which can be used for other routing (192.168.0.55 and 192.168.0.55).
Lastly, we will need to assign the Azure Routing Table we created to our Mid or Backend subnet.
Step 3: Create Access Rules on the Barracuda NG Firewall
By default all outgoing traffic from the mid or backend is blocked by the NG Firewall. Create an access rule to allow access to the Internet.
Download the Barracuda NG Admin to manage our Barracuda NG Firewall running on Azure and login to our Barracuda NG Admin console:
Create a PASS access rule:
Source – Enter our mid or backend subnet
Service – Select Any
Destination – Select Internet
Connection – Select Dynamic SNAT
Click OK and place the access rule higher than other rules blocking the same type of traffic
Click Send Changes and Activate
Our VMs in the mid or backend subnet can now access the Internet via the Barracuda NG Firewall. RDP to my VM sitting on Mid subnet 192.168.1.4, browse to Google.com:
Let’s have a quick look at Barracuda NG Admin Logs 🙂
And we are good to go using same method configuring the rest to protect our Azure environment:
Backend traffic to go pass our Barracuda NG Firewall before hitting the Mid traffic and Vice Versa
Mid traffic to go pass our Barracuda NG Firewall before hitting the Frontend traffic and Vice Versa
I hope you’ve found this post useful – please leave any comments or questions below!