Back to controls

Ensure no Azure SQL Databases allow ingress from 0.0.0.0/0 (ANY IP)

Ensure that no SQL Databases allow ingress from 0.0.0.0/0 (ANY IP).

Category

Controls

High

Applies to

Microsoft Azure

Coverage

null controls, 1 queries

Asset types

1 covered

Overview

Ensure that no SQL Databases allow ingress from 0.0.0.0/0 (ANY IP).

Rationale

Azure SQL Server includes a firewall to block access to unauthorized connections. The range of IP addresses available from specific data centers can be used to define more granular IP addresses.

By default, for a SQL server, a Firewall exists with StartIp of 0.0.0.0 and EndIP of 0.0.0.0 allowing access to all Azure services.

Additionally, a custom rule can be set up with StartIp of 0.0.0.0 and EndIP of 255.255.255.255, allowing access from ANY IP over the Internet.

To reduce a SQL server's potential attack surface, firewall rules should be defined with more granular IP addresses, referencing the range of addresses available from specific data centers.

If Allow Azure services and resources to access this server is 'Checked', this will allow resources outside of the subscription/tenant/organization boundary, within any region of Azure, to effectively bypass the defined SQL Server Network ACL on the public endpoint. A malicious attacker can successfully launch a SQL server password bruteforce attack by creating a virtual machine in any Azure subscription/region from outside the subscription boundary where the SQL Server resides.

Impact

Disabling Allow Azure services and resources to access this server will break all connections to SQL server and Hosted Databases unless custom IP-specific rules are added to the Firewall Policy.

Default Value

By default, the setting Allow Azure services and resources to access this server is set to ON.

Additional Information

Firewall rules configured on individual SQL Database using Transact-SQL overrides the rules set on SQL server. Azure does not provide any Powershell, API, CLI, or Portal option to check database-level firewall rules, and so far, Transact-SQL is the only way to check for them. For comprehensive control over egress traffic on SQL Databases, Firewall rules should be checked using SQL client.

References

  1. https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-a-windows-firewall-for-database-engine-access?view=sql-server-2017
  2. https://docs.microsoft.com/en-us/powershell/module/azurerm.sql/get-azurermsqlserverfirewallrule?view=azurermps-5.2.0
  3. https://docs.microsoft.com/en-us/powershell/module/azurerm.sql/set-azurermsqlserverfirewallrule?view=azurermps-5.2.0
  4. https://docs.microsoft.com/en-us/powershell/module/azurerm.sql/remove-azurermsqlserverfirewallrule?view=azurermps-5.2.0
  5. [https://docs.microsoft.com/en-us/azure/sql-database/sql-database-firewall-configure]https://docs.microsoft.com/en-us/azure/sql-database/sql-database-firewall-configure()
  6. https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-set-database-firewall-rule-azure-sql-database?view=azuresqldb-current
  7. https://docs.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-network-security#ns-2-secure-cloud-services-with-network-controls

Remediation guidance

From Azure Console

  1. Open the SQL server using the Open in Azure button
  2. Under Security, click Networking
  3. Uncheck Allow Azure services and resources to access this server
  4. Set firewall rules to limit access to authorized connections
  5. Save

Using Azure CLI

Disable default firewall rule Allow Azure services and resources to access this server:

az sql server firewall-rule delete --resource-group <resourceGroup> --server <sqlServerName> --name "AllowAllWindowsAzureIps"

Remove a custom firewall rule:

az sql server firewall-rule delete --resource-group <resourceGroup> --server <sqlServerName> --name <firewallRuleName>

Create an appropriate firewall rule, with the start IP address other than 0.0.0.0 and end IP address other than 0.0.0.0 or 255.255.255.255

az sql server firewall-rule create --resource-group <resourceGroup> --server <sqlServerName> --name <firewallRuleName> --start-ip-address "<startIPAddress>" --end-ip-address "<endIPAddress>"

Update a firewall rule

az sql server firewall-rule update --resource-group <resourceGroup> --server <sqlServerNamee> --name <firewallRuleName> --start-ip-address "<startIPAddress>" --end-ip-address "<endIPAddress>"

Using Azure PowerShell

Disable default firewall rule Allow Azure services and resources to access this server:

Remove-AzureRmSqlServerFirewallRule -FirewallRuleName "AllowAllWindowsAzureIps" -ResourceGroupName <resourceGroupName> -ServerName <serverName>

Remove a custom firewall rule:

Remove-AzureRmSqlServerFirewallRule -FirewallRuleName "<firewallRuleName>" -ResourceGroupName <resourceGroupName> -ServerName <serverName>

Create an appropriate firewall rule, with the start IP address other than 0.0.0.0 and end IP address other than 0.0.0.0 or 255.255.255.255

Set-AzureRmSqlServerFirewallRule -ResourceGroupName <resourceGroupName> -ServerName <serverName> -FirewallRuleName "<firewallRuleName>" -StartIpAddress "<startIPAddress>" -EndIpAddress "<endIPAddress>"

Multiple Remediation Paths

Azure

SERVICE-WIDE (RECOMMENDED when many resources are affected): Assign Azure Policy initiatives at management group/subscription scope and trigger remediation tasks.

az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

ASSET-LEVEL: Apply the resource-specific remediation steps above to the listed non-compliant resources.

PREVENTIVE: Embed Azure Policy checks into landing zones and IaC workflows to block or auto-remediate drift.

References for Service-Wide Patterns

  • Azure Policy overview: https://learn.microsoft.com/en-us/azure/governance/policy/overview
  • Azure Policy remediation: https://learn.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
  • Azure Policy initiative structure: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/initiative-definition-structure

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

  • Azure: assign policy initiatives at management group/subscription scope and run remediation tasks.
az policy assignment create --name <assignment-name> --scope /subscriptions/<subscription-id> --policy-set-definition <initiative-id>
az policy remediation create --name <remediation-name> --policy-assignment <assignment-id>

2. Remediate Existing Affected Assets

  • Execute the control-specific Console/CLI steps documented above for each flagged resource.
  • Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

  • Re-scan after each remediation batch.
  • Track exceptions with owner and expiry date.
  • Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

No Azure SQL Databases allow ingress from 0.0.0.0/0 (ANY IP)

Connectors

Microsoft Azure

Covered asset types

SQLServer

Expected check: eq []

{sqlServers(where:{firewallRules_SOME:{startIpAddress_CONTAINS:"0.0.0.0"}}){...AssetFragment}}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon