Update a network list from an automation

You make an automation, such as a SIEM or SOAR playbook or a scheduled script, write the items of a network list through the Azion API or the Azion CLI, and make the same change by hand from Azion Console. To create a list with a dated entry and the rule that denies it, refer to Block addresses until a date.

A firewall rule names its network list by ID, so a change to the items changes what every rule that reads the list matches, with no change to any rule. The automation that already tracks the addresses is the one that writes them, and the platform applies each due date at the next write.

1. An automation that owns every item of the list sends the whole set in one write.
2. An automation that shares the list reads the stored items first, then writes them back with its new entry.
3. A scheduled job writes the stored items back unchanged, so the entries past their due date leave the list.
4. On each write, the platform drops the items already past due and stores the rest as sent. The rules match the new items once the change reaches traffic.

Prerequisites

• A network list of the ip_cidr type, and the firewall rule that reads it. To create both, refer to Block addresses until a date.
• A personal token for the automation, created by a user whose team holds the Edit Network Lists permission. For the permission, refer to Permissions.
• The Azion CLI installed and authorized, for the CLI procedure.
• Access to Azion Console, for the Console procedure. Refer to Access Azion Console.

The examples write the list <network-list-id>, which holds the permanent entry 192.0.2.10 #permanent block, and add 198.51.100.7 until 2030-01-01T00:00:00Z. Replace them with your list, entries, and dates.

Add an entry to the list

A PATCH that sends items replaces the whole array, so an automation that sends only its new entry removes every other one. It reads the stored items, adds its entry, and writes the array back. An entry can carry a due date, --LT and a UTC date and time in whole seconds ending in Z, and a comment after #, last on the line. The comment can name the detection or the ticket behind the entry. The API reports only the first invalid entry of a write, in meta.index and meta.value, so validate the whole array before you send it.

The list holds the new entry beside every entry it held before. The rules that read it match 198.51.100.7 once the change reaches traffic, 46 seconds to about 100 seconds after the write.

Replace the list from your source of truth

When another system already tracks every address, such as a SIEM or an inventory, let it own the list and send the whole set on each write. Each write then leaves exactly what was sent, and the next write repairs one that failed. Each write also overwrites every other editor, so give the list one owner, and keep manual blocks in a list of their own, with its own rule. A list holds 1 to 20,000 items of up to 250 characters each, annotations included.

The list holds the set from your source of truth and nothing else. An entry the source dropped stops matching once the change reaches traffic.

Remove expired entries on a schedule

A due date never removes an entry by itself. The platform reads due dates only when the items are written: each write drops the entries already past due, and an entry whose date passes after the write keeps matching. A scheduled job that writes the stored items back is what ends each block, and how often it runs sets how long an expired entry keeps matching. When every item is past due, the write is refused with 22019, so keep one entry with no due date in the list.

The list holds only the entries still in force, and the rules stop matching the expired address once the change reaches traffic. A PATCH that carries only a name drops nothing, because it writes no items.

Next steps