When you put an application on the web, you can be sure that hackers and bots will probe it for weaknesses soon afterward. If they find weaknesses, then they’ll likely compromise it in either an obvious way, or even worse, in a way that you don’t notice. So before you deploy any web applications, you need to architect a security solution.

The first step is for your application developers to design secure code. That’s a good start, but it’s difficult to ensure that every application can withstand attacks. So you’ll need to put some type of centralized protection in front of all of your applications.

Azure provides a lot of great network security features to help with this, such as DDoS protection, virtual network isolation, and network security groups (which we’ll talk about more in a minute), but you should also add a layer that’s designed to combat a broad array of threats to web apps.

One good option is the Web Application Firewall that comes with the Azure Application Gateway. It’s based on the well-known Open Web Application Security Project (or OWASP) core rule sets. It protects against attacks like:

• SQL injection

• Cross-site scripting

• HTTP request smuggling

• Remote file inclusion, and

• HTTP protocol violations and anomalies

It also detects common misconfigurations in web servers like Apache or IIS.

You can run it in either detection or prevention mode. In detection mode, it simply logs all security alerts. In prevention mode, it actually blocks the attacks that it detects. To monitor the firewall’s activities in either mode, you can look in Azure Monitor, Azure Security Center, and Log Analytics, because they’re all integrated with it.

Although Microsoft’s Web Application Firewall is very capable, you may still want to use a different solution, either because your organization has standardized on a third-party security product or because you need a firewall with additional features. Fortunately, a number of vendors, such as Barracuda and Palo Alto Networks, provide pre-built virtual machines that you can get from the Azure Marketplace. These are known as network virtual appliances.

Ideally, these appliances should be put in a demilitarized zone (or DMZ). This is a perimeter network that keeps unwanted traffic, including attacks, from getting through to your backend network. In this example, the perimeter network and the backend network are two subnets within the same virtual network.

To control the flow of traffic between these two subnets, you can use an NSG (which stands for network security group). An NSG contains security rules that allow or deny traffic to resources in a subnet of a virtual network. They’re similar to firewall rules. You can also apply NSGs to the network interfaces of specific VMs (if they were deployed using Resource Manager) or to all of the traffic to and from specific VMs (if they were deployed using the classic model), but it’s usually better to apply them to an entire subnet.

Here’s an example NSG. It has inbound and outbound rules. The most important are the inbound rules. The first inbound rule allows DNS traffic over port 53 from anything inside the virtual network to the DNS server, which has this address.

Notice that I didn’t have to specify an address range for the source. That’s because Microsoft lets you use service tags instead. This greatly simplifies your rules and makes them easier to read and understand. For example, the VirtualNetwork tag includes the virtual network address space, all connected on-premises address spaces, and all peered virtual networks or virtual networks connected through a VPN gateway. If you had to specify all of those address ranges yourself, the rule would be pretty complicated and it would be easy to make a mistake when creating the rule. Another advantage is that the addresses in a service tag are automatically updated when something changes, so you don’t need to update your rules. In case you’re wondering, you can’t create your own service tags. You can only use the predefined ones.

The second rule allows RDP traffic over port 3389 from the internet to this virtual network so you can remotely administer the VMs. Notice that “Internet” is also a service tag again. The third rule allows traffic to the firewall, which has this address. The next one allows traffic between the web server and the app servers. The destination is a list of both addresses.

After all of these allow rules, we add deny rules. The first one denies all traffic from the internet to this virtual network. Since it has a lower priority than this allow rule, it will only be applied for traffic that doesn’t match the allow rule. Finally, we deny all traffic between the frontend and backend subnets that wasn’t explicitly allowed above. These three rules at the bottom are added by default. You can’t change or delete them, but you can override them with the rules above, which is what we’ve done. To activate this NSG, you’d need to associate it with both the frontend and backend subnets.

By default, the outbound rules allow all outgoing internet traffic. This could be dangerous as your VMs might accidentally leak sensitive information to the internet. You can add a security layer by using forced tunneling.

With this configuration, all internet-bound traffic has to go through your on-premises network before going out to the internet. This gives you the opportunity to run this traffic through an inspection and auditing system that’s installed on-premises.

The way to do this is pretty straightforward. You create a user-defined default route that points to the VPN gateway in your virtual network. Then, on the VPN gateway, you set the default site to the on-premises location where you want to redirect the traffic. If you’re using ExpressRoute rather than a site-to-site VPN, then instead you advertise a default route via the BGP peering sessions.

Since forced tunneling can significantly slow down internet-bound traffic, you usually shouldn’t use it on frontend web servers. It’s more suitable for backend servers.

And that’s it for security strategies.