1. परिचय — DMZ में सिक्योरिटी मॉनिटरिंग के “blind spot” होते हैं #

क्लाउड प्रोवाइडर और होस्टिंग प्रोवाइडर के लिए, DMZ (demilitarized zone) में मौजूद पब्लिक वेब सर्वर और रिवर्स प्रॉक्सी सबसे अधिक निशाना बनाए जाने वाले स्थान हैं।

ऐसी जगहों पर भी syslog forwarding के जरिये लॉग को एकत्रित करने वाली कॉन्फ़िगरेशन असामान्य नहीं है। लेकिन यहाँ एक महत्वपूर्ण आधार-धारणा है:

BASTION का DMZ Agent इस आधार पर डिज़ाइन किया गया है कि “Agent स्वयं भी compromise हो सकता है।” यह लेख “Agent untrust model” और उसे सपोर्ट करने वाले validation engine के डिज़ाइन की व्याख्या करता है।

2. मौजूदा EDR और SIEM Agent क्यों पर्याप्त नहीं हैं #

EDR (Endpoint Detection & Response) और SIEM प्रोडक्ट के Agent फ़ीचर endpoint की विसंगतियों का पता लगा सकते हैं। हालांकि, इनमें से अधिकांश प्रोडक्ट निम्नलिखित आधार-धारणाओं पर आधारित हैं:

1. Agent भरोसेमंद है (= सर्वर साइड द्वारा जारी signed binary)
2. Agent से भेजे गए इवेंट सही हैं (= Agent के अंदर पहले से validate किए गए)
3. यदि Agent चुप है, तो सर्वर सुरक्षित है (= कुछ असामान्य होने पर Agent को सूचित करना चाहिए)

ये धारणाएँ सामान्य समय में वैध हैं, लेकिन compromised DMZ सर्वर पर पूरी तरह विफल हो जाती हैं:

1. Signed binary होने पर भी, यदि root privilege प्राप्त हो जाए, तो Agent प्रोसेस को ही मॉडिफाई किया जा सकता है
2. यदि हमलावर Agent के अंदर की इवेंट validation लॉजिक को समझ ले, तो वह validation पास करने वाले “नकली इवेंट” जनरेट कर सकता है
3. Agent को kill करके नकली Agent शुरू करके, “सामान्य silence” का नाटक किया जा सकता है

BASTION को इन सभी loopholes को बंद करने के लिए डिज़ाइन किया गया है।

3. Agent Untrust Model — तीन ज़िम्मेदारियों का पृथक्करण #

BASTION के Agent और सेंट्रल सर्वर (AI-SLOG) के बीच का संबंध तीन ज़िम्मेदारियों में स्पष्ट रूप से विभाजित है।

मुख्य बिंदु यह है कि “detection” और “validation” भौतिक रूप से अलग किए गए हैं।” भले ही Agent “attack detected” की सूचना दे, AI-SLOG उस पर आंख मूंदकर भरोसा नहीं करता। वह हमेशा एक अलग पाथवे से उसी सर्वर से सीधे प्राप्त raw logs का उपयोग करके स्वतंत्र validation करता है।

     DMZ Server                     AI-SLOG (Internal)
   ┌──────────────┐                ┌──────────────┐
   │  Agent       │── WebSocket ──→│ Receive      │
   │  ・Log Monitor│    (Events)    │              │
   │  ・Primary     │                │   ↓          │
   │    Detection  │                │ Validation   │←─ Raw logs
   │              │                │   Engine     │  (via rsyslog)
   │  ・Block      │←── WebSocket ──│   ↓          │
   │   Execution  │   (block cmd)  │ Send Command │
   │    Only      │                │              │
   └──────────────┘                └──────────────┘
   ↑                                ↑
   Agent cannot do more             Cross-reference with
   than blocking even if lying      raw logs; discard event
                                    if mismatch

4. Validation Engine — Agent इवेंट का raw logs से क्रॉस-रेफ़रेंस #

Validation engine एक ऐसा तंत्र है जो स्वतंत्र रूप से वेरिफ़ाई करता है कि Agent से आने वाले इवेंट “तथ्य” हैं या नहीं।

Agent से आए इवेंट का उदाहरण (attack detection नोटिफ़िकेशन):

{
  "agent_id": "dmz-web-01",
  "event_type": "vuln_scan_detected",
  "src_ip": "203.0.113.42",
  "target": "/.env",
  "timestamp": "2026-05-13T10:23:45+09:00",
  "evidence_lines": [
    "203.0.113.42 GET /.env HTTP/1.1 404",
    "203.0.113.42 GET /.git/config HTTP/1.1 404",
    "203.0.113.42 GET /wp-admin HTTP/1.1 404"
  ]
}

यह इवेंट प्राप्त होने पर, AI-SLOG निम्नलिखित चरणों के जरिये इसे validate करता है:

1. Raw log प्राप्ति: संबंधित DMZ सर्वर के Apache/Nginx लॉग पहले से ही rsyslog के जरिये अलग से प्राप्त किए जा रहे हैं
2. संबंधित timestamp के आसपास सर्च: इवेंट के timestamp के ±30 सेकंड के भीतर उसी IP से आए requests को सर्च किया जाता है
3. evidence_lines से क्रॉस-रेफ़रेंस: Agent जिन तीन लाइनों का दावा करता है, वे वास्तविक लॉग में मौजूद हैं या नहीं, यह वेरिफ़ाई किया जाता है
4. Mismatch होने पर discard: यदि एक भी लाइन मेल नहीं खाती, तो यह इवेंट “संभावित fabrication” मानकर discard कर दिया जाता है और एक warning जारी की जाती है

यदि Agent ईमानदारी से काम करता है, तो evidence_lines वास्तविक लॉग से मेल खाएँगी और validation बिना किसी समस्या के पास होगा। भले ही हमलावर Agent को compromise करके नकली इवेंट भेजे, raw logs से क्रॉस-रेफ़रेंस के जरिये वे आसानी से फ़िल्टर हो जाते हैं।

महत्वपूर्ण बात यह है कि raw log प्राप्ति का पाथवे और Agent इवेंट का पाथवे पूरी तरह अलग हैं। rsyslog के जरिये लॉग forwarding, Agent प्रोसेस से अलग पाथवे पर चलती है, और भले ही हमलावर Agent को कंट्रोल कर ले, वह इंटरनल साइड के rsyslog reception को मॉडिफाई नहीं कर सकता।

5. Agent Permission डिज़ाइन — न्यूनतम की गई क्षमताएँ #

Agent को दी गई permissions भी बिल्कुल न्यूनतम स्तर तक सीमित हैं।

विशेष रूप से महत्वपूर्ण यह डिज़ाइन है कि “Agent स्वयं blocks नहीं हटा सकता।” भले ही हमलावर Agent का कंट्रोल प्राप्त कर ले, वह अपने IP को unblock करके दोबारा प्रवेश नहीं कर सकता।

तो फिर यदि गलती से detect हो जाए, तो वैध users को unblock कैसे किया जाता है? इसे दो पाथवे से हल किया गया है: “24 घंटे बाद automatic expiration” (जिसका विवरण आगे है) और AI-SLOG साइड से मैनुअल unblock कमांड।

6. Heartbeat Freeze — निष्क्रिय होने पर सेफ़्टी डिवाइस #

हमने पहले कहा कि “यदि Agent चुप है तो सुरक्षित है” इस धारणा पर भरोसा नहीं करना चाहिए। तो फिर Agent के रुक जाने की स्थिति को BASTION वास्तव में कैसे संभालता है?

हर Agent समय-समय पर AI-SLOG को heartbeat भेजता है। जब यह एक निश्चित अवधि के लिए बाधित हो जाता है, तो BASTION निम्नलिखित करता है:

1. संबंधित Agent से आने वाले सभी नए इवेंट को freeze करना (प्रोसेस किए बिना discard)
2. Slack के जरिये ऑपरेटरों को सूचित करना
3. Agent restart और heartbeat recovery तक इवेंट स्वीकारना बंद रखना

यह उस परिदृश्य के खिलाफ प्रतिउपाय है जिसमें Agent चुप रहते हुए चुपचाप गलत जानकारी भेजता रहे। यह कल्पनीय है कि हमलावर वास्तविक लॉग forwarding रोककर केवल heartbeat भेजता रहे, लेकिन इस स्थिति में, अलग rsyslog पाथवे से यह पता लगाया जा सकता है कि “लॉग अचानक बंद हो गए हैं।”

दूसरे शब्दों में, हमने जानबूझकर Agent की स्थिति जाँचने के लिए कई पाथवे रखे हैं।

7. 24 घंटे की automatic expiration — Blocking को स्थायी बनने से रोकना #

Agent द्वारा execute किए गए blocks (ufw deny आदि) को 24 घंटे बाद अपने आप expire होने के लिए डिज़ाइन किया गया है।

# Agent-side cron.hourly
/opt/bastion-agent/bastion-ufw-prune.sh
# → Judge elapsed time from timestamp embedded in ufw comments
# → Delete entries exceeding 24 hours with ufw delete
# → Do not wait for unblock instruction from AI-SLOG (autonomous local operation)

इस डिज़ाइन के तीन उद्देश्य हैं:

1. False positive के स्थायी होने को रोकना: भले ही गलत detection से अस्थायी रूप से block हो जाए, यह 24 घंटे बाद खुद रिकवर हो जाता है
2. Agent को unblock authority की जरूरत नहीं: Automatic expiration के साथ, Agent को unblock permissions देने की कोई आवश्यकता नहीं है
3. AI-SLOG dependency कम करना: Expiration की प्रोसेसिंग Agent पर locally पूरी होती है; AI-SLOG down हो तो भी कोई समस्या नहीं

यदि वही हमलावर 24 घंटे बाद वापस आता है, तो स्वाभाविक रूप से फिर detect होकर दोबारा block हो जाता है। जब तक हमलावर की गतिविधि जारी रहती है, blocking सक्रिय होती रहती है।

8. Implementation का निर्णय — WebSocket क्यों चुना गया #

Agent और AI-SLOG के बीच का communication WebSocket से implement किया गया है। इसके पीछे की सोच साझा करता हूँ।

विशेष रूप से महत्वपूर्ण यह है कि “Agent → AI-SLOG इवेंट भेजना” और “AI-SLOG → Agent block कमांड” एक ही connection में संभाले जा सकते हैं। इससे firewalls के पार communication आसान हो जाता है और operational बोझ काफी कम हो जाता है।

इसके अलावा, इसे HAProxy जैसे स्टैंडर्ड रिवर्स प्रॉक्सी पर terminate किया जा सकता है (HTTP जैसी ही semantics), इसलिए TLS termination और authentication integration मौजूदा assets के साथ काम करते हैं।

9. डिज़ाइन के tradeoffs और सीमाएँ #

ईमानदारी से कहें तो, इस तंत्र की अपनी सीमाएँ हैं।

1. Validation engine की computational cost: चूंकि हर Agent इवेंट का raw logs से क्रॉस-रेफ़रेंस किया जाता है, इवेंट की मात्रा बढ़ने के साथ प्रोसेसिंग टाइम बढ़ता है। BASTION cost नियंत्रित करने के लिए evidence_lines को 3-5 लाइनों तक सीमित रखता है और time window से सर्च रेंज को संकीर्ण करता है।

2. Raw log प्राप्ति पाथवे की redundancy: Validation engine rsyslog के जरिये आए लॉग का उपयोग करता है, लेकिन यदि rsyslog ही रुक जाए, तो validation नहीं हो सकता। इसके लिए, rsyslog का health monitoring अलग से implement किया गया है, जो रुकने पर तुरंत alert देता है।

3. Validation लॉजिक की transparency: Validation लॉजिक का विस्तृत विवरण सार्वजनिक करने से हमलावर उसे circumvent करने वाले नकली इवेंट डिज़ाइन कर सकते हैं। इसलिए, specific validation algorithm का विवरण सार्वजनिक नहीं है (यह लेख केवल अवधारणाओं की व्याख्या करता है)।

4. Block हटाने का operational बोझ: चूंकि Agent के पास हटाने की authority नहीं है, गलत blocks को तुरंत हटाने के लिए AI-SLOG साइड से ऑपरेशन जरूरी है। यह “24 घंटे सहन करें या ऑपरेटर मैन्युअल रूप से हस्तक्षेप करें” बन जाता है।

ये “compromised Agent पर भरोसा न करें” की मूल धारणा से उत्पन्न होने वाले अपरिहार्य tradeoffs हैं। डिज़ाइन जानबूझकर सुविधा की तुलना में सिक्योरिटी की ओर झुकाया गया है।

10. वास्तविक operations में परिणाम — हमारे environment में validation #

BASTION का DMZ Agent वर्तमान में तीन पब्लिक वेब सर्वरों पर production में चल रहा है। इस लेख के लिखे जाने तक:

• Agent rejected इवेंट: 0 (validation द्वारा discard किए गए इवेंट = सभी इवेंट वैध)
• Agent heartbeat विसंगतियाँ: 0 (heartbeat में शून्य रुकावट)
• गलत blocking की घटनाएँ: 0 (कंपनी IP/पार्टनर IP की blocking शून्य)
• 24-घंटे expiration से अनपेक्षित removal: 0 (सब कुछ अपेक्षा के अनुरूप काम कर रहा है)

यह ऐसी स्थिति है जहाँ “Agent ईमानदारी से काम करता है, इसलिए validation पास होता है,” और untrust model की असली कीमत तभी दिखती है जब compromise होता है। यह सामान्य समय में चुपचाप काम करता है और कुछ होने पर ऑपरेटरों की रक्षा करता है।

11. भविष्य का विकास #

Agent और validation engine वर्तमान में व्यावहारिक उपयोग में हैं, लेकिन सुधार की गुंजाइश मौजूद है।

• Go language migration: वर्तमान Python Agent implementation को Go में migrate करना, जिससे single-binary distribution संभव हो (ग्राहक environments में deployment आसान हो जाए)
• Signature verification: Agent binary की signature validation और startup पर self-verification लॉजिक जोड़ना
• Audit log blockchain: Validation engine के निर्णयों के इतिहास की tamper-proof recording implement करना (ग्राहक auditing के लिए)
• कई validation पाथवे: केवल rsyslog ही नहीं बल्कि SNMP और network flow जानकारी का उपयोग करके multi-layered validation

इन्हें क्रमिक रूप से implement किया जाएगा।