लोकल LLM के साथ इंफ्रास्ट्रक्चर लॉग्स का स्वचालित विश्लेषण करने का तंत्र बनाने की कहानी

8 min read

2026.04 ／ Tech Blog ／ BASTION

लोकल LLM के साथ ऑटोमेटेड इंफ्रास्ट्रक्चर लॉग एनालिसिस सिस्टम बनाना #

AI हर 15 मिनट में firewall, ऑथेंटिकेशन इंफ्रास्ट्रक्चर, स्विच, लोड बैलेंसर और वेब सर्वर के लॉग्स का ऑटोमैटिक विश्लेषण करता है — anomaly डिटेक्ट करना, severity तय करना और remediation सुझाना — सब कुछ Slack नोटिफिकेशन के जरिए। लॉग डेटा कभी बाहर नहीं भेजा जाता।

हमने इसे क्यों बनाया #

वजह बिल्कुल सीधी थी: हमारे पास लॉग्स देखने का समय ही नहीं था।

BESTNET-CLOUD में कई firewall, L2/L3 स्विच, Windows AD, लोड बैलेंसर और वेब सर्वर चलते हैं। हर एक syslog आउटपुट जेनरेट करता है, लेकिन इंसानों के लिए रोज़ाना सारे लॉग्स मैन्युअली देखना व्यावहारिक नहीं है। रिसोर्स मॉनिटरिंग के लिए हम Zabbix इस्तेमाल करते हैं, लेकिन syslog का कंटेंट पढ़कर यह तय करना कि किसी attack pattern को नज़रअंदाज़ करना है या उस पर एक्शन लेना है — यह काम अब भी इंसानों के जिम्मे था।

AWS DevOps Agent (मार्च 2026 में GA) और Azure Security Copilot जैसी सेवाएँ अब पब्लिक क्लाउड साइड पर AI-आधारित लॉग एनालिसिस देती हैं। लेकिन ये मुख्य रूप से क्लाउड रिसोर्सेज़ को टार्गेट करती हैं और ऑन-प्रेमिसेस फिजिकल उपकरणों के syslog को सीधे पार्स और एनालाइज़ करने की क्षमता नहीं रखतीं। इसके अलावा, चूँकि लॉग डेटा क्लाउड वेंडर के AI इंफ्रास्ट्रक्चर पर भेजा जाता है, ये समाधान closed-network एनवायरनमेंट में इस्तेमाल नहीं किए जा सकते।

इसलिए हमारे पास खुद बनाने का ही विकल्प बचा। सौभाग्य से, लोकल LLM की परफ़ॉर्मेंस अब प्रैक्टिकल स्तर तक पहुँच चुकी है, और सभी ज़रूरी कंपोनेंट ओपन सोर्स के रूप में उपलब्ध हैं।

सिस्टम आर्किटेक्चर #

इस सिस्टम का नाम BASTION है — यानी किला या आख़िरी मोर्चा, जो closed-network एनवायरनमेंट में इंफ्रास्ट्रक्चर की रक्षा करने के विज़न को दर्शाता है।

आर्किटेक्चर काफ़ी सीधा-सादा है।

इस्तेमाल किए गए कंपोनेंट नीचे दिए गए हैं — सभी ओपन सोर्स या फ्री टियर:

कंपोनेंट	भूमिका	लाइसेंस
rsyslog	सभी डिवाइसों से centralized syslog रिसेप्शन, हर होस्ट के हिसाब से सेव	OSS (GPL)
Shell script suite	हर डिवाइस के लॉग की summarization, parsing, preprocessing	इन-हाउस डेवलपमेंट
OpenClaw	AI एजेंट फ्रेमवर्क (LLM इंटीग्रेशन, Slack इंटीग्रेशन, कमांड एग्ज़िक्यूशन)	OSS
Qwen2.5-14B	लोकल LLM (जापानी लॉग एनालिसिस, anomaly डिटेक्शन)	OSS (Apache 2.0)
GPUStack	GPU inference सर्वर (OpenAI-compatible API प्रदान करता है)	OSS
Slack (Socket Mode)	नोटिफिकेशन और दोतरफ़ा इंटरैक्शन	फ्री टियर

अहम बात: इंटरनेट कनेक्शन की ज़रूरत नहीं। Slack Socket Mode सिर्फ़ आउटबाउंड कनेक्शन से काम करता है — कोई inbound पोर्ट खोलने की ज़रूरत नहीं। LLM inference GPUStack के जरिए लोकली पूरा होता है। लॉग डेटा के एनवायरनमेंट से बाहर जाने का कोई रास्ता ही नहीं है।

डेटा फ्लो की डिटेल्स #

1. लॉग कलेक्शन (rsyslog) #

हर डिवाइस से UDP/TCP पोर्ट 514 पर syslog रिसीव किया जाता है और hostname, साल, महीने और प्रोग्राम नाम के हिसाब से व्यवस्थित डायरेक्टरियों में स्टोर किया जाता है।

/var/log/remote/
  fw-primary/2026/04/filterlog.log
  ad-server/2026/04/Security-Auditing.log
  lb-server/2026/04/loadbalancer.log
  ...

2. लॉग summarization (summarize.sh) #

हर 15 मिनट में cron summarize.sh चलाता है, जो हर डिवाइस के लिए पिछले 30 मिनट के इवेंट्स निकालता है और एक structured टेक्स्ट summary जेनरेट करता है।

सबसे अहम डिज़ाइन सिद्धांत: raw लॉग्स कभी सीधे LLM को न दें। Raw लॉग्स redundant होते हैं और भारी मात्रा में टोकन खा जाते हैं। हम पहले उन्हें shell scripts से पार्स करते हैं — “firewall के 5 blocks, टॉप 5 attack source IPs ये हैं, AD login failures की संख्या X” जैसी summaries बनाकर — और फिर सिर्फ़ summary को natural language में judgement के लिए LLM को पास करते हैं।

चूँकि हर डिवाइस का लॉग फ़ॉर्मेट पूरी तरह अलग होता है, parsing हर डिवाइस के लिए अलग से लिखी जाती है। उदाहरण के लिए, firewall का filterlog कॉमा-सेपरेटेड फील्ड्स इस्तेमाल करता है जिसमें source IP पोज़िशन 19 पर और destination port पोज़िशन 22 पर होता है। Windows AD के लॉग्स में binary डेटा होता है, जिसके लिए grep -a चाहिए। scripts में समाहित यही डिवाइस-विशिष्ट ज्ञान इस सिस्टम का असली मेहनत वाला हिस्सा है।

3. AI एनालिसिस (analyze.sh) #

Summary टेक्स्ट OpenClaw के जरिए लोकल LLM (Qwen2.5-14B) को दिया जाता है। Prompt में निर्देश होता है: “severity तय करो और डिटेक्ट हुई anomalies तथा recommended remediation JSON फ़ॉर्मेट में लौटाओ।”

यहाँ दो अहम डिज़ाइन निर्णय लागू होते हैं।

Session isolation: हर एनालिसिस के लिए एक डायनामिक session ID जेनरेट की जाती है, ताकि पिछली बातचीत का इतिहास context को दूषित न करे। LLM पिछले नतीजों से प्रभावित होकर judgement में भटक सकते हैं, इसलिए हम हर एनालिसिस के लिए fresh context सुनिश्चित करते हैं।

False positive कंट्रोल: सामान्य ऑपरेशन पैटर्न (Nextcloud LDAP का periodic authentication, Kerberos का automatic authentication, firewall द्वारा external scan blocking आदि) system prompt में परिभाषित किए गए हैं, जिससे LLM को इन्हें noise मानकर बाहर रखने के criteria मिल जाते हैं। ऑपरेशन के दौरान हम पैटर्न धीरे-धीरे जोड़ते रहते हैं।

4. नोटिफिकेशन (notify.sh) #

LLM एनालिसिस के नतीजे severity के हिसाब से रंग-कोडिंग के साथ Slack पर भेजे जाते हैं (critical=लाल, high=नारंगी, medium=पीला, low=हरा)।

medium और उससे ऊपर के लिए, दूसरा विस्तृत एनालिसिस अपने-आप भेजा जाता है। इस दूसरे मैसेज में raw लॉग्स की टॉप 50 लाइनें शामिल होती हैं, जिससे ऑपरेटर सिर्फ़ नोटिफिकेशन से ही “क्या हुआ” और raw डेटा — दोनों की पुष्टि कर सकते हैं।

5. इंटरैक्टिव एनालिसिस (Slack दोतरफ़ा) #

शेड्यूल्ड एनालिसिस के अलावा, Slack में @OpenClaw-Monitor firewall analysis मेंशन करने पर निर्दिष्ट डिवाइस का तुरंत विस्तृत एनालिसिस ट्रिगर होता है। “क्या VPN authentication के कोई संकेत हैं?” या “चेक करो कि कोई single IP कई attack methods तो नहीं आज़मा रहा” जैसी natural language क्वेरीज़ सपोर्टेड हैं।

चूँकि OpenClaw bash कमांड चला सकता है, भविष्य में automated remediation — डायनामिक रूप से firewall rules जोड़ना, सर्विसेज़ को isolate करना आदि — तक विस्तार संभव है।

GPU आवश्यकताएँ #

रिसोर्स की खपत हैरानी की हद तक कम है।

आइटम	खपत
Model (Qwen2.5-14B Q4 quantized)	~9GB
KV cache (16K tokens)	~1–2GB
कुल	~10–11GB

एक V100 16GB GPU आराम से पर्याप्त headroom देता है। चूँकि यह हर 15 मिनट की batch processing है, GPU लगातार occupied नहीं रहता। GPUStack एक OpenAI-compatible API देता है, इसलिए model बदलने के लिए सिर्फ़ configuration बदलना काफ़ी है।

सपोर्टेड डिवाइस #

डिवाइस टाइप	एनालिसिस
Firewall	Attack block काउंट, attack source IPs, पोर्ट डिस्ट्रीब्यूशन, VPN errors
ऑथेंटिकेशन (AD)	लॉगिन success/failure/lockout, failure source IPs, failed accounts
लोड बैलेंसर	हर backend की 5xx error रेट
L2/L3 स्विच	Link down, loops, storm डिटेक्शन
वेब सर्वर	HTTP status डिस्ट्रीब्यूशन, sensitive URLs, 4xx/5xx source IPs

जो भी डिवाइस syslog आउटपुट देता है, उसे एक parse script जोड़कर मॉनिटर्ड फ्लीट में शामिल किया जा सकता है। FortiGate, Cisco, Palo Alto वगैरह सभी इसी तरह सपोर्टेड हैं।

ऑपरेशन से मिले इनसाइट्स #

Judgement के लिए LLM, डेटा प्रोसेसिंग के लिए scripts #

शुरू में हमने raw लॉग्स सीधे LLM को देने की कोशिश की, लेकिन उसने syslog के field positions ग़लत पहचाने और calculation में गड़बड़ियाँ हुईं। LLM सटीक numeric aggregation में कमज़ोर होते हैं। अब parsing, counting और summarization shell scripts संभालती हैं; LLM का काम सिर्फ़ summary पढ़कर यह judge करना है कि “anomaly है या normal?” और “remediation क्या हो?”।

False positive कंट्रोल ऑपरेशन के साथ परिपक्व होता है #

पहला हफ़्ता false positives से भरा रहा। AD पर Kerberos computer account के periodic authentication से 1,000 से ज़्यादा login success रिपोर्टें बनीं, और Nextcloud के LDAP इंटीग्रेशन को “suspicious login attempts” के रूप में फ्लैग किया गया। हर पैटर्न को normal behavior के रूप में system prompt में जोड़ने से लगभग दो हफ़्तों में noise ख़त्म हो गया।

Session isolation अनिवार्य है #

Sessions को सीधे इस्तेमाल करने पर पिछले एनालिसिस के नतीजे context में बने रहते हैं, जिससे LLM “पिछली रिपोर्ट की तुलना में…” जैसा ग़ैर-ज़रूरी context घुसा देता है। सिक्योरिटी एनालिसिस के लिए हर बार fresh नज़रिया चाहिए, इसलिए हम हर एनालिसिस के लिए session ID डायनामिक रूप से जेनरेट करते हैं।

“कुछ नहीं हुआ” वाली रिपोर्टों की भी वैल्यू है #

शुरुआत में बार-बार आने वाले LOW नोटिफिकेशन noise जैसे लगते थे। समय के साथ हमें एहसास हुआ कि ये रिपोर्टें हमें भरोसा दिलाती हैं कि “सिस्टम सामान्य रूप से चल रहा है।” जब नोटिफिकेशन आने बंद हो जाते हैं, तो हम पकड़ लेते हैं कि “मॉनिटरिंग खुद ही रुक गई है” — इन्हीं नियमित रिपोर्टों की बदौलत।

आगे की योजनाएँ #

फ़िलहाल फ्लो “detect → notify” है। हम इसे “detect → AI judge → auto-remediate” तक बढ़ाने की योजना में हैं।

ठोस रूप से, हम attack source IPs की ऑटोमैटिक blocking (सीधे firewall APIs कॉल करके), brute force डिटेक्शन पर auto-blocking, और असामान्य रिसोर्स उपयोग पर auto-throttling लागू करेंगे। हम एक hybrid configuration भी explore कर रहे हैं जिसमें BASTION मौजूदा मॉनिटरिंग सिस्टम्स (Zabbix, AWS CloudWatch, Azure Monitor) से webhook के जरिए अलर्ट रिसीव करे, cross-system AI एनालिसिस करे, और automated remediation एग्ज़िक्यूट करे।

सारांश #

हमने लोकल LLM (Qwen2.5-14B) + GPUStack + OpenClaw + rsyslog + shell scripts से ऑटोमेटेड इंफ्रास्ट्रक्चर लॉग एनालिसिस साकार किया। यह एक V100 16GB GPU पर चलता है, लॉग डेटा एनवायरनमेंट से कभी बाहर नहीं जाता, और मासिक ऑपरेटिंग लागत सिर्फ़ GPU की बिजली है।

सभी कंपोनेंट ओपन सोर्स हैं, इसलिए कोई भी इस आर्किटेक्चर को दोहरा सकता है। हालाँकि, पूर्ण ऑपरेशन तक पहुँचने के लिए डिवाइस-विशिष्ट लॉग parsing, false positive पैटर्न का संचय, और system prompts की tuning ज़रूरी है — जो आसान काम नहीं है और operational ज्ञान माँगता है।

BASTION फ़िलहाल BESTNET LLC के अपने इंफ्रास्ट्रक्चर (BESTNET-CLOUD) पर प्रोडक्शन में 24/7 चल रहा है।

Closed-network एनवायरनमेंट के लिए AI-आधारित सिक्योरिटी मॉनिटरिंग में दिलचस्पी है? बेझिझक संपर्क करें।

BASTION Service Page Contact

Updated on 2026 वर्ष 6 माह 10 दिन

What are your feelings