XEIZE
/Vulnerability documentation/IaC/Azure Resource Manager/Azure SQL server firewall rule specifies the full IPv4 range

Azure SQL server firewall rule specifies the full IPv4 range

Restrict the full IPv4 range in an Azure SQL server firewall to required sources, and review public network access alongside database authentication.

Description

In an ARM or Bicep Microsoft.Sql/servers/firewallRules resource, setting startIpAddress to 0.0.0.0 and endIpAddress to 255.255.255.255 permits the full IPv4 range. When this range applies to a public endpoint, the firewall no longer restricts clients by their source address.

Actual connectivity also depends on the server's network settings. If publicNetworkAccess is disabled, this firewall rule alone does not enable public connections. Database authentication and permissions remain separate requirements even when a connection is possible.

Setting both endpoints to 0.0.0.0 is a separate exception permitting connections from Azure resources, including resources in other customers' subscriptions. It differs from the full IPv4 range but should not be treated as internal-only connectivity.

Potential impact

  • When public connections are enabled and the all-IPv4 rule applies, the firewall does not restrict source addresses on the IPv4 internet.
  • External clients with a permitted network path can attempt database authentication. Data access still requires valid authentication and permissions, but broad network access can increase opportunities to misuse leaked credentials.

Remediation

  • If public connections are required, allow only the actual clients' source IPv4 addresses. Where NAT is used, define the range using the public source address the server sees. Set startIpAddress and endIpAddress to individual IPv4 addresses in ascending order, not CIDRs.
  • Remove rules permitting the full IPv4 range, and review other server-level and database-level firewall rules together with public network settings.
  • For an architecture using private endpoints, verify the required private connectivity before disabling public network access. Using a VNet or jump host does not by itself remove a public path. Manage authentication and database permissions separately.

Examples

These excerpts compare the full IPv4 range with a restricted range. Do not use the first example's administrator-name and password strings as real credentials; validate the preview API version and resource schema before deployment. The second example is a partial configuration that assumes an existing sample server, not a complete deployment template.

Entire IPv4 range

bicep
resource sqlServer1 'Microsoft.Sql/servers@2021-02-01-preview' = {
  name: 'sqlServer1'
  location: resourceGroup().location
  properties: {
    administratorLogin: 'adminUsername'
    administratorLoginPassword: 'adminPassword'
  }
}

resource sqlServer1AllowAll 'Microsoft.Sql/servers/firewallRules@2021-02-01-preview' = {
  parent: sqlServer1
  location: resourceGroup().location
  name: 'AllowAll'
  properties: {
    endIpAddress: '255.255.255.255'
    startIpAddress: '0.0.0.0'
  }
}

Restricted address range

bicep
resource sampleFirewall 'Microsoft.Sql/servers/firewallRules@2021-02-01-preview' = {
  name: 'sample/firewall'
  properties: {
    startIpAddress: '192.168.1.2'
    endIpAddress: '192.168.1.254'
  }
}

Explanation:

  • First example: The start and end addresses cover the full IPv4 range. Network settings determine whether a public connection path exists; database access also requires authentication and permissions.
  • Second example: The range specifies private addresses from 192.168.1.2 through 192.168.1.254. Verify that they are the actual client source addresses seen by the service. Entering private addresses alone does not configure private connectivity or a trusted administration network.

References

XEIZE DocumentationTechnical support