Separating application tiers in a hosted environment: network rules that limit damage

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

A hosted business application can be built in layers: a web or remote access tier that users connect to, an application tier that does the work, and a database tier that holds the data. If all of them share one flat network where any server can reach any other on any port, an attacker who gets into the server users connect to can try the others next, including the database.

Separating the tiers, and allowing only the connections each tier needs, limits how far a compromise can spread. This article explains the principle, the two layers of rules involved, and the SQL Server ports such rules have to handle.

Why it matters

The Australian Signals Directorate states that network segmentation and segregation is one of the most effective security controls in preventing malicious actors from easily propagating throughout networks once initial access has been gained. The server that accepts connections from users or the internet is exposed to more attackers than the servers behind it, so it is a likely first target. What it can reach decides what an attacker can reach next.

How it works

Zones by criticality

ASD's Information Security Manual (ISM) controls include that networks are segregated into multiple zones according to the criticality of servers, services and data, and that network access controls limit traffic within and between network segments to only that required for business purposes. ASD also states that administrative infrastructure should be segregated from other assets, and that an organisation's networks are segregated from its service providers' networks.

For a three-tier application, that gives three zones plus a management zone:

ASD notes that virtual LANs can implement segmentation when the networks belong to the same security domain.

Two layers of rules

Network rules sit between the zones, in the hosting provider's virtual firewall or routing. They decide which zone can open connections to which, on which ports.

Host rules sit on each server. Microsoft states that Windows Firewall is enabled by default on all Windows editions, and that by default it blocks incoming traffic unless solicited or matching a rule, while allowing outgoing traffic unless a rule matches. Rules can specify the source address, so the database server can accept its port only from the application servers' addresses.

Independently configured and verified network and host rules can reduce exposure if one layer is misconfigured. They do not guarantee that one catches the other: copying the same permissive mistake into both defeats that protection. After a move or clone, check the effective host profile, source addresses and assigned policies, as well as network rules, rather than assuming saved rules still provide the intended protection.

SQL Server ports

Microsoft's guidance on SQL Server and Windows Firewall lists the ports a rule has to account for:

• TCP 1433 for a default instance.
• Named instances use a dynamic port chosen when the database engine starts, unless an administrator fixes one.
• UDP 1434 for the SQL Server Browser service, which tells clients which port a named instance is on. Microsoft notes the Browser service isn't required if clients are configured to connect to the instance's specific port.

A fixed port for each named instance makes the database tier's rule precise: one known port, from known sources. Microsoft also advises limiting the scope of each port opening, and describes the option to allow any computer, including those on the internet, as not recommended.

What to choose and why

A sound starting design:

1. Inventory the flows. For each tier, list what connects to it, from where and on which port. Ask the application vendor for its port list rather than guessing.
2. Deny by default between zones, then allow only the listed flows.
3. Fix SQL Server ports for named instances and allow them only from the application tier.
4. Keep administration in its own zone. Remote desktop and management ports accept connections only from administrator workstations.
5. Mirror the network rules in Windows Firewall on each server, restricted by source address.
6. Log denied connections so a missing rule shows up as a log entry rather than a mystery.

Questions to ask a hosting provider:

• Are my tiers in separate network segments, and who changes the rules between them?
• Is the default between segments deny?
• Is the management network separate from my production servers' networks?
• Can I see the current rule set and the log of denied connections?

A hypothetical example

An invented application has two web servers, one application server listening on TCP 8443, and one SQL Server named instance fixed at TCP 1450. The illustrative application flows are users to web on 443, web to application on 8443, and application to database on 1450; the illustrated administrative flow is management workstations to the servers on remote desktop. This is not a complete infrastructure rule set. Separately inventory and authorise required DNS, time, identity, monitoring, backup and other shared-service flows; deny traffic not approved in that complete inventory. The ports 8443 and 1450 are invented for illustration; use your vendor's figures.

Risks and limits

• Too-tight rules break the application. Test the rule set on isolated test servers with synthetic data before applying it to production, and change one rule at a time.
• Undocumented dependencies exist. Printing, licensing servers, file shares and authentication need flows too. Test representative transactions, scheduled and infrequent jobs, and record untested paths; one test run cannot establish complete dependency coverage.
• Segmentation limits spread; it does not stop the first compromise. Patching and strong sign-in still matter.
• Outgoing traffic is allowed by default in Windows Firewall. Restricting it is possible but needs more care.
• No commands are given here. Microsoft's firewall page shows how rules are created.

Sources

Opened 14 November 2026.

• ASD: Guidelines for networking, Information Security Manual, September 2026.
• Microsoft Learn: Windows Firewall overview; displayed Last updated: 2026-05-27.
• Microsoft Learn: Configure the Windows Firewall to allow SQL Server access; displayed Last updated: 2026-05-20.

Related service: VPC networking.

Related future topics

• Provider administrator access in managed hosting.
• SQL Server and the application: same server or separate?
• Remote desktop gateways for hosted applications.

Learning notes

• Segmentation limits how far an attacker can move after the first compromise.
• Zone by criticality; allow only the flows the business needs.
• Use network rules between zones and Windows Firewall rules on each server.
• Fix SQL Server named instance ports and allow them only from the application tier.
• Keep administration in its own zone.

This article was originally published on 14 November 2026.