Guard one path with a network list
Deny the addresses of a network list on one path, such as /admin, and keep every other path open, with one firewall rule in Azion Console, the CLI, or the API.
You can deny listed addresses on one path, /admin, from Azion Console, the Azion CLI, or the API. Every other path of the workload stays open to those addresses. One firewall rule chains two criteria: Network compares the client address with an ip_cidr network list, and Request Uri compares the path. Use this rule to keep some addresses out of an administration area, a login form, or an API route. It also lets you try a list on one path before a rule applies the list to every request. To deny listed addresses on every path instead, refer to Block requests by IP, ASN, or country.
Select the interface you work in. The prerequisites and every task on this page switch to match it.
Prerequisites
- A workload bound to a firewall through its deployment. That firewall receives the rule you create in this guide.
- Network Shield turned on for that firewall. Network Shield is on by default when a firewall is created. To turn it on, refer to Set a firewall’s main settings.
- Access to Azion Console.
Create the address list
An ip_cidr list holds IP addresses and ranges, one per item, in IPv4 or IPv6. A range takes CIDR notation, such as 198.51.100.0/24. A client matches the list when its address is an item or falls inside a range. The list in this guide holds one IPv4 address, one IPv4 range, and one IPv6 range. Its type stays ip_cidr for the life of the list. For the fields of a list and the format of each type, refer to Network list fields and List types.
To create the list with the Azion CLI, save its definition as network-list.json:
Then create the list from the file:
The CLI prints the ID of the list it created:
The list Blocked addresses holds the three items, and the rule refers to the list by that ID.
Create the rule that guards the path
The rule holds two criteria in one block. The first, Network, carries the conditional if. The second, Request Uri, carries and, which makes it a condition that must also be true. The rule therefore denies a request only when the client is in the list and the path starts with /admin. When either criterion is false, the rule runs nothing, and the firewall moves on to its next rule. For how criteria and blocks combine, refer to Conditionals.
azion create firewall-rule reads the rule from a JSON file. To create the rule with the Azion CLI, save this body as rule.json. Put your list ID in place of <network-list-id>, as a bare number with no quotes:
Then create the rule from the file. Write the ID of the firewall bound to your workload in place of <firewall-id>:
The CLI prints the ID of the rule it created:
The firewall holds the rule, active, and the rule denies the listed addresses on the paths under /admin.
Confirm that the path denies the listed addresses
Expect the rule to reach traffic 6 minutes 29 seconds to 9 minutes 18 seconds after you create it. A workload bound shortly before can need several minutes for its first rule, and no duration is guaranteed. Until the rule reaches traffic, /admin answers the listed addresses as every other path does.
After that, a client in the list receives HTTP 403 on /admin and every path under it. Its body is Azion’s default error page, headed Forbidden. A request from a listed address to /admin gets this response:
The Your IP row is the client address that the firewall compared with the list. A request from the same address to a path outside /admin passes the rule. It reaches the application, which answers as it does for any client. For the response that a denied client receives, refer to Deny (403 Forbidden).
The starts with operator matches every path that begins with its argument. The argument /admin therefore also covers /admin/users and /administrator. To choose the path that a block needs, refer to Scope a block to the path that needs it.
A change to the list’s items after the rule is live reaches traffic sooner than the rule did: in 46 seconds to about 100 seconds. Meanwhile, one request can reflect the old items and the next one the updated items. Send the request again until the answers agree. For every propagation time, refer to Propagation.