Update a network list from an automation
Write the items of a network list from a SIEM playbook or a script: add a dated entry, replace the whole list, and drop expired entries.
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.
- An automation that owns every item of the list sends the whole set in one write.
- An automation that shares the list reads the stored items first, then writes them back with its new entry.
- A scheduled job writes the stored items back unchanged, so the entries past their due date leave the list.
- 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
Console
- A network list of the
ip_cidrtype, 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.
- Access to Azion Console. 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.
Console
To add the entry by hand:
Access Azion Console > Edge Libraries > Network Lists, and select the list.
In the List field, add 198.51.100.7 --LT2030-01-01T00:00:00Z #<detection-id> on its own line.
Azion Console confirms with the message Your Network List has been updated.
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.
In the Block attackers automatically from SIEM detections use case, this section takes these values:
| Setting | Value |
|---|---|
| List | siem-blocklist, which holds the permanent entry 192.0.2.10 #permanent block |
| New entry | The detected address, a due date 24 hours after the detection, and the detection’s ID as the comment, such as 198.51.100.23 --LT2030-01-01T00:00:00Z #DET-4471, with 2030-01-01T00:00:00Z standing for the detection time plus 24 hours |
| Write | PATCH /v4/workspace/network_lists/<network-list-id>, whose items hold every current entry and the new one: 192.0.2.10 #permanent block and 198.51.100.23 --LT2030-01-01T00:00:00Z #DET-4471 for DET-4471 |
The API answers 200 and stores the items exactly as sent. The playbook validates every entry before it sends the array, because a refused write names only the first invalid entry.
In the Block attackers automatically from SIEM detections use case, expect:
- The write kept every other entry. The list’s
itemshold the permanent entry, every earlier detection still in force, and the new entry.
In the Screen file uploads for malicious content use case, this section takes these values:
| Setting | Value |
|---|---|
| Later senders | <sender-address> --LT<upload-date-plus-7-days> #<request-id>, added by reading upload-senders and writing it back with the new entry |
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.
Console
To replace the items by hand:
Access Azion Console > Edge Libraries > Network Lists, and select the list.
In the List field, replace every line with the set from your source of truth, one entry per line.
Azion Console confirms with the message Your Network List has been updated.
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.
Console
To remove an expired entry by hand:
Access Azion Console > Edge Libraries > Network Lists, and select the list.
In the List field, delete the line whose due date has passed. The form flags that line with the --LT date must be in the future.
Azion Console confirms with the message Your Network List has been updated.
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.
In the Block attackers automatically from SIEM detections use case, this section takes these values:
| Setting | Value |
|---|---|
| List | siem-blocklist. The permanent entry 192.0.2.10 #permanent block carries no due date, so the job’s write is never refused for holding only expired entries |
| Schedule | Every hour, from the SIEM or SOAR platform’s scheduler |
| Write | The same items sent back with a PATCH. After the due date of DET-4471, written as <past-due-date>, the items are 192.0.2.10 #permanent block and 198.51.100.23 --LT<past-due-date> #DET-4471 |
The API answers 200 and stores 192.0.2.10 #permanent block alone. The address receives the application’s answers again once the change reaches traffic.
Confirm the block
Run the playbook for a test detection on an address you control, then request the application from that address:
In the Block attackers automatically from SIEM detections use case, expect:
- A detection becomes a block. After the playbook runs for a test detection on an address you control, a request to
https://www.example.com/from that address answers403within about 100 seconds of the playbook’s write. - An expired block ends. Once a test entry’s due date has passed and the expiry job has run, the job’s write returns the items without that entry, and a request from that address answers with the application’s status again.