Listen to this Post
Introduction:
In an era of sophisticated cyber threats, exposing virtual machines and web applications directly to the internet is an unacceptable risk. This guide deconstructs a real-world implementation of a secure, zero-trust cloud architecture on Microsoft Azure, where an Nginx web server is deployed without a public IP, shielded by multiple layers of defensive controls. We will explore the core components—Azure Firewall, Bastion, and Network Security Groups—that work in concert to create an impregnable environment.
Learning Objectives:
- Design and implement a segmented Azure Virtual Network (VNet) for security isolation.
- Configure Azure Firewall with DNAT rules to securely route and filter inbound traffic.
- Harden network access using Azure Bastion for administration and Network Security Groups (NSGs) for internal micro-segmentation.
You Should Know:
1. Virtual Network (VNet) Design & Subnet Architecture
A properly segmented network is the foundation of any secure cloud deployment. It allows you to control traffic flow between different tiers of your application, limiting the blast radius in case of a breach. In this architecture, subnets are created for specific functions: one for the firewall, one for the Bastion host, and one for the application itself.
Step‑by‑step guide explaining what this does and how to use it.
Step 1: Create the Virtual Network. This is the isolated container for all your resources. Using the Azure CLI, you can create a new VNet.
`az network vnet create –resource-group MyResourceGroup –name SecureVNet –address-prefix 10.0.0.0/16 –location “East US”`
Step 2: Create Specialized Subnets. Segregate your network based on function. Critical subnets include `AzureFirewallSubnet` (a mandatory name for the firewall), `AzureBastionSubnet` (also mandatory, for the Bastion service), and a general-purpose subnet like `Subnet-1` for your application VMs.
`az network vnet subnet create –resource-group MyResourceGroup –vnet-name SecureVNet –name Subnet-1 –address-prefixes 10.0.1.0/24`
What This Does: This segmentation ensures that even if an attacker compromises the web server, they cannot directly reach the management (Bastion) or firewall control planes, enforcing a critical security boundary.
2. Azure Firewall + DNAT for Secure Ingress
Azure Firewall acts as a controlled, stateful gateway. Instead of exposing your VM, you expose the firewall. A Destination Network Address Translation (DNAT) rule is then used to forward specific, authorized traffic to the internal VM, all while hiding its real IP address.
Step‑by‑step guide explaining what this does and how to use it.
Step 1: Deploy Azure Firewall. Deploy the firewall into the dedicated AzureFirewallSubnet. Note its private and public IP addresses once provisioning is complete.
Step 2: Configure a DNAT Rule. This rule is the cornerstone of secure access. It states: “If traffic arrives at the firewall’s public IP on port 4000 from my specific laptop IP, translate the destination to the web server’s private IP on port 80.”
Navigation: In the Azure Portal, go to your Azure Firewall resource -> Rules -> DNAT rules collection.
Add Rule:
Name: `WebApp-Access`
Source Type: IP Address
Source: ``
Protocol: TCP
Destination Ports: 4000
Destination Addresses: ``
Translated Address: ``
Translated Port: 80
What This Does: It creates a pin-hole tunnel. Only your machine can initiate a connection, and the web server itself remains completely hidden from the public internet, accessible only as http://<Firewall-Public-IP>:4000.
3. Azure Bastion for Secure VM Administration
Traditional SSH access via a public IP is a major attack vector. Azure Bastion provides a secure and seamless way to connect to your VMs directly through the Azure portal over TLS, eliminating the need for open SSH/RDP ports.
Step‑by‑step guide explaining what this does and how to use it.
Step 1: Provision the Azure Bastion Service. This is a regional service deployed into the dedicated AzureBastionSubnet.
`az network bastion create –name MySecureBastion –resource-group MyResourceGroup –vnet-name SecureVNet –location “East US” –public-ip-address MyBastionIP`
Step 2: Connect to Your VM. Navigate to your VM in the Azure Portal and click “Connect” -> “Bastion”. Authenticate with your Azure credentials and the VM’s local username/password.
What This Does: It brokers a secure, out-of-band management connection. Your SSH session is tunneled through the Azure backbone, meaning your VM’s SSH port (22) is never exposed to the internet, thwarting brute-force attacks.
4. Nginx Web Server Deployment & Hardening
The application layer must also be secured. Deploying a common web server like Nginx inside the isolated subnet is the final piece.
Step‑by‑step guide explaining what this does and how to use it.
Step 1: Deploy an Ubuntu VM. Create a standard VM without a public IP, placing it in Subnet-1.
Step 2: Install and Configure Nginx. Connect via Bastion and run the following commands:
`sudo apt update && sudo apt install nginx -y`
`sudo systemctl enable nginx && sudo systemctl start nginx`
Step 3: Harden the Nginx Configuration. Create a custom HTML page and modify the default configuration to remove server tokens, enhancing security.
`sudo nano /etc/nginx/nginx.conf`
Add or edit the line: `server_tokens off;`
`sudo systemctl reload nginx`
What This Does: This provides the actual web service. The hardening step prevents information leakage, making it slightly more difficult for an attacker to fingerprint your server version.
- Network Security Groups (NSGs) – Layered Internal Protection
NSGs act as distributed firewalls at the subnet and network interface level. They provide a crucial layer of defense-in-depth, controlling traffic within your VNet to prevent lateral movement.
Step‑by‑step guide explaining what this does and how to use it.
Step 1: Create an NSG for the Application Subnet. Associate this NSG with Subnet-1.
Step 2: Configure Inbound Security Rules. The principle of least privilege is key. Define explicit allow rules and block everything else by default.
Rule 1: Allow HTTP from Firewall.
Source: `AzureFirewall’s Private IP` (e.g., 10.0.0.4)
Source Port: “
Destination: “
Destination Port: `80`
Protocol: `TCP`
Action: `Allow`
Rule 2: Allow SSH from Bastion.
Source: `AzureBastionSubnet` (e.g., 10.0.2.0/27)
Source Port: “
Destination: “
Destination Port: `22`
Protocol: `TCP`
Action: `Allow`
What This Does: Even if the firewall is somehow misconfigured, the NSG ensures the web server can only receive web traffic from the firewall itself and SSH connections from the Bastion service. All other internal and external connection attempts are dropped.
What Undercode Say:
- Zero-Trust is Actionable, Not Abstract. This architecture is a textbook implementation of the zero-trust mantra “never trust, always verify.” Every component, from the network path to the management plane, requires explicit verification and is designed from the ground up to assume a hostile environment.
- Layered Defense is Non-Negotiable. Relying on a single security control is a recipe for disaster. The combination of VNet segmentation, a next-generation firewall, a secure administrative jumpbox, and micro-segmentation via NSGs creates a defensive depth that is extremely difficult for an attacker to penetrate.
This implementation moves beyond theoretical security frameworks and demonstrates a production-ready pattern. The use of a client-specific DNAT rule is particularly sophisticated, reducing the attack surface to a single IP address. While this setup is highly resilient, its operational complexity and cost (from services like Azure Firewall and Bastion) must be justified by the sensitivity of the workload. For less critical applications, an Application Gateway with a Web Application Firewall might be a more cost-effective alternative, but it would not provide the same level of network-level isolation. This design is ideal for protecting administrative interfaces, legacy applications, or any system where direct internet exposure is deemed too risky.
Prediction:
The future of cloud security will be dominated by architectures that completely eliminate public endpoints for backend services. The model demonstrated here—using a tightly controlled firewall as the sole internet gateway—will become the standard for protecting critical infrastructure. We will see a rapid decline in the use of public IPs on VMs, replaced by PaaS/FaaS services or proxy-based access patterns. Furthermore, AI-driven security postures will automatically generate and enforce such complex, zero-trust network policies, making this high level of security the default rather than the expert-led exception.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Emmanuelduruaku Successfully – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
