AI ने हमला detect किया → Slack पर approve → firewall में auto-block जुड़ गया #
हमने BASTION के “detect → notify” loop में “automatic response” जोड़ा। जब AI किसी port scan का पता लगाता है, तो वह Slack पर एक block proposal post करता है, और जब कोई इंसान उसे approve करता है, तो block rule तुरंत OPNsense firewall में जुड़ जाता है। 24 घंटे बाद auto-removal।
सिर्फ़ detection और notification काफ़ी नहीं हैं #
BASTION पहले logs का analysis करके anomalies detect करता था और Slack के ज़रिए notify करता था (Part 1)। लेकिन notification के बाद का काम — attack source IP को firewall में block करना — इंसान को खुद OPNsense admin console खोलकर operate करना पड़ता था।
रात 3 बजे notification आती है, और आप अगली सुबह log in करके block लगाते हैं। उन 6 घंटों में attacker आराम से scan कर सकता है।
हमने BASTION में reactive defense implement किया। जब AI किसी attack का पता लगाता है, तो वह अपने आप firewall block जोड़ने का proposal देता है, और Slack पर approve करते ही rule तुरंत OPNsense पर apply हो जाता है।
पूरा flow #
| Step | किसके द्वारा execute | Action |
|---|---|---|
| 1. Attack detection | analyze.sh (हर 15 मिनट) | Log analysis से port scans और brute-force attempts का पता चलता है। Severity को HIGH mark किया जाता है |
| 2. Block proposal | propose-block.sh | Whitelist check → Deduplication → Slack पर proposal post |
| 3. Human approval | Operator | Slack command: @OpenClaw-Monitor approve block-XXXXX |
| 4. Block execution | fw-action.sh | OPNsense API से IP को Alias (BASTION_AutoBlock) में जोड़ा जाता है |
| 5. Auto-removal | auto-expire.sh (hourly cron) | 24 घंटे बाद IP को Alias से हटा दिया जाता है |
व्यवहार में operation #
1. Slack पर block proposal आता है #
जब हर 15 मिनट वाला regular analysis severity: HIGH detect करता है, तो attack source IP के लिए एक block proposal अपने आप Slack पर post हो जाता है।
Block proposal [block-20260423-003]
Attack source IP: xxx.xxx.119.51
Detection reason: port_scan — 3,003 blocks/failures
Severity: HIGH
Auto-removal: 24 hours later
Approve: @OpenClaw-Monitor approve block-20260423-003
Reject: @OpenClaw-Monitor reject block-20260423-003
※ If no response within 30 minutes, will be automatically rejected.
Block proposal [block-20260423-004]
Attack source IP: xxx.xxx.47.173
Detection reason: port_scan — 977 blocks/failures
Severity: HIGH
Auto-removal: 24 hours later
Block proposal [block-20260423-005]
Attack source IP: xxx.xxx.102.23
Detection reason: port_scan — 965 blocks/failures
Severity: HIGH
Auto-removal: 24 hours later
प्रति analysis अधिकतम 3 proposals। Blocks की संख्या के हिसाब से top IPs descending order में चुने जाते हैं।
2. Approve करते ही firewall में तुरंत reflect #
जब आप Slack पर approval command भेजते हैं, तो fw-action.sh OPNsense API call करके IP को block list में जोड़ देता है।
Block execution complete [block-20260423-003]
IP: xxx.xxx.119.51
Auto-removal: 2026-04-24T13:37:14+09:00
OPNsense की तरफ़ IP को BASTION_AutoBlock नाम के Alias में जोड़ा जाता है। इस Alias को reference करने वाला WAN block rule पहले से configure किया हुआ है, इसलिए API से Alias में IP जोड़ते ही block तुरंत active हो जाता है।
3. 24 घंटे बाद auto-removal #
auto-expire.sh hourly cron पर चलता है और expire हो चुके blocks को अपने आप हटा देता है।
Auto-removal: xxx.xxx.119.51 (24 hours elapsed)
अगर हटाए जाने के बाद वही IP फिर से scan करता है, तो अगले analysis में वह फिर से propose हो जाएगा।
Safety mechanisms #
चूँकि हम AI से firewall operations automate कर रहे हैं, हमें ऐसे safety mechanisms चाहिए जो misclassification की वजह से legitimate traffic को block होने से रोकें। हमने defense की 5 layers implement की हैं।
| Layer | विवरण | उद्देश्य |
|---|---|---|
| Whitelist | Internal IPs, DNS, कंपनी के global IPs कभी block नहीं होते | अपने ही traffic को block होने से रोकना |
| Slack approval gate | Execution से पहले इंसान द्वारा verification (शुरुआती phase) | AI की misclassifications पकड़ना |
| Rate limiting | प्रति घंटे अधिकतम 10 blocks | असामान्य mass blocking रोकना |
| Auto-removal | 24 घंटे बाद block अपने आप हट जाता है | Misclassification होने पर भी auto-recovery |
| Emergency flush | Slack से सभी blocks को तुरंत हटाना | Business impact होने पर emergency rollback |
Whitelist matching का implementation #
Whitelist matching Python के ipaddress module से implement की गई है। यह CIDR notation (10.0.0.0/8 आदि) support करती है और built-in checks के ज़रिए private IPs, loopback, link-local, multicast और reserved addresses को अपने आप exclude कर देती है।
# 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 #
Block mechanism ख़ुद OPNsense का एक Alias (IP addresses का group) है। हम पहले से “BASTION_AutoBlock” नाम का Alias बनाते हैं और एक WAN block rule configure करते हैं जो इस Alias को 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 सीधे runtime table को manipulate करता है, इसलिए एक ही API call से block तुरंत active हो जाता है। Firewall rules को reload करने की ज़रूरत नहीं पड़ती।
Audit log #
सभी blocks, removals, approvals, rejections और timeouts audit log में record होते हैं।
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
Tag ([PROPOSE] / [BLOCK] / [EXPIRE] आदि) से grep करके सिर्फ़ specific operations निकाले जा सकते हैं।
धीरे-धीरे autonomy की ओर #
फ़िलहाल हम Slack approval-gate वाला तरीक़ा इस्तेमाल कर रहे हैं, लेकिन design ऐसी है कि नतीजे जमा होने के साथ धीरे-धीरे autonomy लाई जा सके।
| Phase | Model | Migration की शर्त |
|---|---|---|
| Phase 1 (वर्तमान) | Slack approval gate | — |
| Phase 2 | Conditional autonomy | High confidence + एक तय block count या उससे ज़्यादा → auto-execute। बाक़ी मामलों में approval gate |
| Phase 3 | Full autonomy | लगातार 3 महीनों तक misclassification rate 0.1% से नीचे |
यह धीरे-धीरे क्यों कर रहे हैं? #
BASTION के development के दौरान हमने LLM hallucinations का अनुभव किया, जहाँ उसने “ऐसे incidents गढ़ दिए जो कभी हुए ही नहीं।” एक account के बारे में “18 बार lock out” होने की रिपोर्ट आई, लेकिन logs में असली event count शून्य था। अगर reactive defense पहले implement हो चुका होता, तो हम phantom attacks के लिए IPs block कर बैठते। यही अनुभव हमारे “execute करने से पहले इंसान से verify कराओ” वाले design decision का आधार है।
Slack approval gate की सीमाएँ अभी से दिखने लगी हैं #
OpenClaw के ज़रिए Slack approval में हमने ऐसे मामले देखे हैं जहाँ LLM batch processing के दौरान कुछ commands execute करने में fail हो जाता है, फिर भी “completed” report कर देता है। जब बीच में कोई agent-based LLM हो, तो इस तरह की uncertainty structurally टाली नहीं जा सकती। Full automation (direct pipeline analyze.sh → propose-block.sh → fw-action.sh) में, चूँकि हम LLM की response generation को bypass कर देते हैं, यह समस्या ग़ायब हो जाती है।
सारांश #
BASTION का reactive defense, log analysis → block proposal → Slack approval → OPNsense API block → 24-hour auto-removal के पूरे flow को automate करता है। Safety की 5 layers (whitelist, approval gate, rate limiting, auto-removal, emergency flush) misclassifications से होने वाले business impact को कम से कम रखती हैं।
फ़िलहाल हम Slack approval-gate वाले तरीक़े से operate कर रहे हैं, लेकिन result data जमा करके धीरे-धीरे autonomy लाएँगे। जो monitoring system पहले “detect → notify” पर ख़त्म हो जाता था, वह अब “detect → judge → respond → auto-remove” पर loop close करता है।
BASTION एक ऐसी service है जो isolated environments में AI security monitoring साकार करती है।