Detection and notification alone are not enough #

BASTION previously worked by analyzing logs to detect anomalies and notifying via Slack (Part 1). However, the action that follows notification—blocking the attack source IP in the firewall—required a human to manually open the OPNsense admin console and operate it.

A notification arrives at 3 AM, and you log in the next morning to apply the block. In those 6 hours, the attacker can scan freely.

We implemented reactive defense in BASTION. When AI detects an attack, it automatically proposes adding a firewall block, and approving it on Slack immediately applies the rule to OPNsense.

Overall flow #

Operation in practice #

1. Block proposal arrives on Slack #

When the regular 15-minute analysis detects severity: HIGH, a block proposal for the attack source IP is automatically posted to Slack.

Up to 3 proposals per analysis. Top IPs are selected by number of blocks, in descending order.

2. Approval immediately reflects in firewall #

When you send the approval command on Slack, fw-action.sh calls the OPNsense API to add the IP to the block list.

On the OPNsense side, the IP is added to an Alias called BASTION_AutoBlock. A WAN block rule referencing this Alias is configured in advance, so adding an IP to the Alias via API immediately activates the block.

3. Auto-removal after 24 hours #

auto-expire.sh runs on an hourly cron and automatically removes expired blocks.

If the same IP scans again after removal, it will be proposed again in the next analysis.

Safety mechanisms #

Since we are automating firewall operations with AI, we need safety mechanisms to prevent misclassification from blocking legitimate traffic. We have implemented 5 layers of defense.

Whitelist matching implementation #

Whitelist matching is implemented using Python’s ipaddress module. It supports CIDR notation (10.0.0.0/8 etc.) and automatically excludes private IPs, loopback, link-local, multicast, and reserved addresses via built-in checks.

# Whitelist matching flow
1. Built-in check: is_private / is_loopback / is_link_local / is_multicast / is_reserved
2. File matching: Check each line in block-whitelist.txt (single IP or CIDR)
3. Result: exit 0=block prohibited / exit 1=block allowed

OPNsense API integration #

The block mechanism itself is an OPNsense Alias (a group of IP addresses). We create an Alias called “BASTION_AutoBlock” in advance and configure a WAN block rule that uses this Alias as the source.

# Add IP (execute block)
curl -k -u "${API_KEY}:${API_SECRET}" \
  -X POST "${OPNSENSE}/api/firewall/alias_util/add/BASTION_AutoBlock" \
  -d '{"address":"attack_source_ip"}'

# Remove IP (remove block)
curl -k -u "${API_KEY}:${API_SECRET}" \
  -X POST "${OPNSENSE}/api/firewall/alias_util/delete/BASTION_AutoBlock" \
  -d '{"address":"attack_source_ip"}'

alias_util directly manipulates the runtime table, so a single API call immediately activates the block. Firewall rule reloading is not necessary.

Audit log #

All blocks, removals, approvals, rejections, and timeouts are recorded in the audit log.

2026-04-23 13:31:33 [PROPOSE] new block-20260423-003 ip=xxx.xxx.119.51 reason=port_scan count=3003
2026-04-23 13:37:14 [BLOCK]   approved block-20260423-003 ip=xxx.xxx.119.51 expires=2026-04-24T13:37:14
2026-04-24 00:00:03 [EXPIRE]  auto-expire block-20260423-003 ip=xxx.xxx.119.51 api=done

Grep by tag ([PROPOSE] / [BLOCK] / [EXPIRE] etc.) to extract specific operations only.

Gradual autonomy #

Currently we use a Slack approval-gate approach, but the design allows for gradual autonomy as we accumulate results.

Summary #

BASTION’s reactive defense fully automates the flow of log analysis → block proposal → Slack approval → OPNsense API block → 24-hour auto-removal. The 5 safety layers (whitelist, approval gate, rate limiting, auto-removal, emergency flush) minimize business impact from misclassifications.

We are currently operating with a Slack approval-gate approach, but we will accumulate result data and gradually introduce autonomy. The monitoring system that previously ended at “detect → notify” now closes the loop at “detect → judge → respond → auto-remove.”