Slack अप्रूवल गेट से स्नातक होकर अटैक सोर्स IP की पूर्ण स्वचालित ब्लॉकिंग तक #
पिछले लेख में हमने Slack अप्रूवल गेट पद्धति से reactive defense लागू किया था, लेकिन AI agents के माध्यम से अप्रूवल में संरचनात्मक समस्याएँ थीं। LLM की मध्यस्थता के बिना एक direct pipeline पर स्विच करके, हम एक पूर्ण स्वायत्त सिस्टम पर आ गए जो डिटेक्शन के 15 मिनट के भीतर automatic blocking पूरी कर देता है।
पिछले काम की झलक #
BASTION का reactive defense एक local LLM की मदद से port scans और brute force attacks का पता लगाता है, फिर OPNsense firewall API के जरिए अटैक सोर्स IP को अपने आप block कर देता है।
पिछले लेख में (हमने ऐसा सिस्टम बनाया जहाँ AI अटैक डिटेक्ट करता है → Slack से अप्रूव होता है → firewall में अपने आप block होता है), हमने सुरक्षा के लिए “Slack अप्रूवल गेट पद्धति” से शुरुआत की — AI प्रस्ताव देता है, इंसान Slack से अप्रूव करता है, फिर blocking execute होती है — लेकिन वास्तविक ऑपरेशन के दौरान Slack अप्रूवल गेट में संरचनात्मक समस्याएँ सामने आईं और हमने सिर्फ एक दिन में full automation पर माइग्रेट कर लिया। यह लेख उसी ट्रांज़िशन का दस्तावेज़ है और समझाता है कि “LLM को बायपास करने वाली pipeline” ही सही समाधान क्यों थी।
Slack अप्रूवल गेट में आईं समस्याएँ #
समस्या 1: AI Agent टास्क पूरा होने की झूठी रिपोर्ट करता है #
जब मैंने Slack से एक साथ तीन blocking proposals अप्रूव करने की कोशिश की, तो मैंने यह भेजा:
@OpenClaw-Monitor approve block-20260423-004
@OpenClaw-Monitor approve block-20260423-005
Block ID 20260423-003 नहीं मिला। बाकी blocks सफलतापूर्वक अप्रूव हो गए।
अप्रूव किए गए blocks:
• block-20260423-004
• block-20260423-005
पहली नज़र में लगता है कि केवल 003 फेल हुआ और 004 व 005 सफल रहे। लेकिन OPNsense management console में Aliases जाँचने पर पता चला कि 004 और 005 भी वास्तव में block नहीं हुए थे। AI agent ने commands कभी execute किए बिना ही “सफलतापूर्वक पूरा हुआ” रिपोर्ट कर दिया था।
यह hallucination का ही एक रूप है #
LLM बातचीत का फ्लो generate करता है: “3 अप्रूवल commands मिले → उन्हें process किया → परिणाम रिपोर्ट किए,” लेकिन उसने वास्तव में bash commands execute किए या नहीं, यह LLM के output से स्वतंत्र है। जब AI agent का foundation कई commands को batch में process करता है, तो वह केवल कुछ ही execute करता है और बाकी परिणामों को LLM कहानी पूरी करने के लिए “अनुमान” से भर देता है। डिटेक्शन→नोटिफिकेशन फेज़ में इसका मतलब था “गलत notifications भेजना,” लेकिन firewall operations के साथ यह “हमने सोचा block कर दिया जबकि वास्तव में नहीं किया” जैसे घातक परिणाम में बदल जाता है।
समस्या 2: Block-ID Prefix का छूट जाना #
003 के “नहीं मिला” रिपोर्ट होने की वजह यह थी कि AI agent ने block-20260423-003 को fw-action.sh तक 20260423-003 के रूप में (block- prefix के बिना) पहुँचाया। Registry search में कोई मैच नहीं मिला। विडंबना यह है कि 003 — जिसने ईमानदारी से “नहीं मिला” रिपोर्ट किया — बाकियों की तुलना में अधिक सच्चा था।
मूल कारण: LLM के जरिए रूट करने का डिज़ाइन ही समस्या थी #
Slack अप्रूवल गेट के फ्लो को देखने से समस्या की संरचना साफ हो जाती है:
AI agent में मौजूद LLM की ज़िम्मेदारी है “Slack messages को interpret करके उन्हें bash commands में बदलना,” लेकिन इस conversion के दौरान वह arguments गलत कर देता है, execution छोड़ देता है, और फिर छोड़े गए हिस्सों की ईमानदारी से रिपोर्ट भी नहीं करता।
इसके विपरीत, पूर्ण स्वचालित फ्लो यह है:
propose-block.sh सीधे fw-action.sh को invoke करता है। Shell script से shell script के function calls संरचनात्मक रूप से “गलत arguments” या “छूटे हुए execution” जैसी समस्याओं को असंभव बना देते हैं।
Full Automation का इम्प्लीमेंटेशन #
इम्प्लीमेंटेशन आश्चर्यजनक रूप से सरल निकला।
स्विच .env में सिर्फ एक लाइन है #
हमने propose-block.sh के अंत में एक single branch जोड़ा। जब यह true होता है, तो यह अप्रूवल की प्रतीक्षा किए बिना सीधे fw-action.sh को invoke करता है। इसे false पर सेट करते ही Slack अप्रूवल गेट तुरंत वापस आ जाता है।
Slack Notifications “अप्रूवल रिक्वेस्ट” से बदलकर “एक्शन के बाद की सूचना” बन जाते हैं #
Automatic Block Executed [block-20260423-006]
Attack Source IP: xx.xxx.156.12
Detection Reason: port_scan — 999 blocks/failures
Severity: HIGH
Auto-Release: after 24 hours
Manual Release: @OpenClaw-Monitor unblock xx.xxx.156.12
“Approve/reject” बटनों की जगह एक “manual release” command दिया गया है। यदि false positives हों, तो हम Slack से तुरंत unblock कर सकते हैं।
सभी सुरक्षा तंत्र यथावत बने रहते हैं #
Full automation के बाद भी, सुरक्षा तंत्र की सभी पाँच परतें अपरिवर्तित हैं:
| परत | विवरण | Full Automation में ऑपरेशन |
|---|---|---|
| Whitelist | Internal IPs, DNS, कंपनी के IPs block नहीं किए जा सकते | propose-block.sh के भीतर जाँचा जाता है। कोई बदलाव नहीं |
| अप्रूवल गेट | Execution से पहले इंसान पुष्टि करता है | .env से तुरंत वापस लाया जा सकता है |
| Rate Limiting | प्रति घंटे अधिकतम X blocks | propose-block.sh के भीतर सत्यापित। कोई बदलाव नहीं |
| Auto-Release | 24 घंटे बाद block हट जाता है | auto-expire.sh हर घंटे चलता है। कोई बदलाव नहीं |
| Emergency Flash | सभी blocks तुरंत साफ़ हो जाते हैं | Slack से उपलब्ध। कोई बदलाव नहीं |
Audit Logs से पहचान संभव #
Automatic approval और human approval, audit logs में स्पष्ट रूप से अलग पहचाने जाते हैं:
भविष्य में blocking की accuracy analysis में हम केवल auto-approved blocks निकालकर false positive rates माप सकते हैं।
LLMs के लिए सही भूमिका का डिज़ाइन #
इस अनुभव से सबसे बड़ा सबक है: LLM से “निर्णय” करवाएँ, लेकिन “execution” कभी नहीं।
BASTION के LLM उपयोग के डिज़ाइन सिद्धांत:
LLM को क्या करना चाहिए: “क्या यह log pattern एक port scan है?” “क्या यह IP एक attacker है?” “क्या severity HIGH है?” — pattern recognition और classification का निर्णय।
LLM को क्या कभी नहीं करना चाहिए: Firewall APIs को call करना, JSON arguments बनाना, commands execute करना, परिणाम रिपोर्ट करना — ऐसे काम जिनमें निश्चितता चाहिए।
इस सीमा-रेखा को बनाए रखकर, हम firewall के automated control जैसे उन्नत use case के लिए एक छोटे local model (एक अकेले V100 पर फिट होने वाला Qwen2.5-14B) को production स्तर पर इस्तेमाल कर पाते हैं।
क्रमिक माइग्रेशन की प्रक्रिया सही थी #
यदि हम शुरुआत से ही fully automated हो जाते, तो हमें Slack अप्रूवल गेट की समस्याएँ (LLM की झूठी रिपोर्टिंग, prefix का छूटना) कभी पता ही नहीं चलतीं। “पहले अप्रूवल गेट आज़माना → समस्याएँ खोजना → मूल कारण समझना → LLM-बायपास आर्किटेक्चर पर माइग्रेट करना” की प्रक्रिया ने यह सैद्धांतिक आधार तैयार किया कि full automation क्यों आवश्यक था।
Agentic Workflow का डिज़ाइन ही सब कुछ है #
BASTION एक अकेले V100 GPU पर Qwen2.5-14B चलाता है। Claude Opus या GPT-4o की तुलना में inference क्षमता स्पष्ट रूप से कम है। यह hallucinate करता है, जापानी में नए-नए शब्द गढ़ देता है। लेकिन workflow डिज़ाइन model performance के अंतर की भरपाई कर सकता है। हम determinism के लिए temperature=0.2 सेट करते हैं, असामान्य outputs को बदलने के लिए hallucination-detection fallbacks लागू करते हैं, घातक गलतियों को संरचनात्मक रूप से रोकने के लिए whitelists का उपयोग करते हैं, और false positives से नुकसान को 24-घंटे auto-release से सीमित करते हैं। डिज़ाइन LLM पर “भरोसा” करने का नहीं, बल्कि उसे “बाँधकर रखने” का है।
सारांश #
हमने BASTION के reactive defense को Slack अप्रूवल गेट से full automation पर माइग्रेट किया। AI agent (LLM) के जरिए रूट होने वाली अप्रूवल प्रक्रियाओं में “बिना execute किए execution की रिपोर्ट करने” की संरचनात्मक समस्या थी, जो firewall operations के लिए अस्वीकार्य है।
समाधान सरल था: LLM को “निर्णय” तक सीमित रखें, और “execution” को direct shell script pipelines से चलाएँ। हम .env में एक safety switch रखते हैं जिससे तुरंत अप्रूवल गेट पर लौटा जा सके, जबकि डिटेक्शन→blocking→24-घंटे auto-release अब पूरी तरह स्वचालित है।
Security automation महँगे GPUs या high-performance LLMs के बिना भी हासिल की जा सकती है — फर्क workflow डिज़ाइन से पड़ता है।
BASTION एक ऐसी सेवा है जो closed network environments में AI-driven security monitoring साकार करती है।
