Splunk Enterprise Security

Splunk Enterprise Security की कोरिलेशन सर्च जो notable event बनाती हैं, उन्हें Status200 के सुरक्षा इवेंट में इम्पोर्ट करें। वहां आप उन्हें अपने लॉग, ट्रेस और मेट्रिक्स के साथ खोजते हैं, हर दूसरे स्रोत के साथ उनका सहसंबंध देखते हैं, और जो मायने रखते हैं उनके लिए ऑन-कॉल को पेज करते हैं। Status200 उन्हें आपके search head पर, आपके बनाए Splunk यूज़र के रूप में, एक सर्च चलाकर पढ़ता है, और Splunk में कुछ नहीं बदलता। क्योंकि यह बस एक सर्च है, यह सिर्फ़ notable event ही नहीं, बल्कि कोई भी इंडेक्स या किसी भी सेव की गई सर्च का आउटपुट इम्पोर्ट करता है।

यह कैसे काम करता है#

हर मिनट Status200 हर उस सक्षम कनेक्शन से पोल करता है जिसका पोल अंतराल बीत चुका है। एक पोल search head के REST API के ज़रिए, पिछले पोल के बाद बनी पंक्तियों पर आपकी सर्च चलाता है, और हर पंक्ति को एक OCSF Detection Finding इवेंट (क्लास 2004) के रूप में सहेजता है। इसके बाद पहचान नियम, मॉनिटर और डैशबोर्ड इसे किसी भी दूसरे स्रोत के सुरक्षा इवेंट की तरह मानते हैं।

शुरू करने से पहले#

• Status200 में Project Owner, Project Admin या Security Admin रोल। Security Member और Security Viewer कनेक्शन और उनका रन इतिहास देख सकते हैं, पर उन्हें बदल नहीं सकते।
• Splunk Enterprise 9.0.1 या बाद का वर्शन चलाने वाला search head, या Splunk Cloud Platform। Status200 मैनेजमेंट पोर्ट पर, आमतौर पर 8089, उसके REST API से बात करता है। पोर्ट 8000 पर Splunk Web REST API नहीं देता।
• Status200 के लिए एक Splunk यूज़र, जिसके रोल में search क्षमता हो और जो वह इंडेक्स पढ़ सके जिसे सर्च पढ़ती है: notable event के लिए notable। Enterprise Security के ess_analyst और ess_user रोल दोनों देते हैं। कनेक्शन सिर्फ़ पढ़ता है, इसलिए रोल को और कुछ नहीं चाहिए।
• एक search head जिस तक Status200 HTTPS पर पहुंच सके। Status200 Cloud इंटरनेट से कनेक्ट करता है, इसलिए search head को एक सार्वजनिक पते की ज़रूरत है: निजी पते अस्वीकार किए जाते हैं। सेल्फ-होस्टेड Status200 अपने ऐप और वर्कर कंटेनर से कनेक्ट करता है, और आपके निजी नेटवर्क पर search head तक पहुंच सकता है, जब तक DATA_SOURCE_BLOCK_PRIVATE_ADDRESSES true न हो।

कनेक्शन सेट करें#

कनेक्शन Splunk ऑथेंटिकेशन टोकन से, या यूज़रनेम और पासवर्ड से ऑथेंटिकेट करता है।

1. ऑथेंटिकेशन टोकन बनाएं#

   1. Splunk Web में Settings → Tokens खोलें। अगर Splunk कहे कि टोकन ऑथेंटिकेशन बंद है, तो पहले Enable Token Authentication चुनें।
   2. New Token चुनें। User में Status200 के लिए बनाया गया Splunk यूज़र डालें, और Audience में बताएं कि टोकन किस लिए है, जैसे Status200 security events।
   3. एक Expiration चुनें, या कोई नहीं। एक्सपायर होने वाला टोकन कनेक्शन को तब तक रोक देता है जब तक आप उसे बदल न दें।
   4. Create चुनें और टोकन कॉपी करें। Splunk इसे सिर्फ़ एक बार दिखाता है।

   इसके बजाय पासवर्ड से ऑथेंटिकेट करने के लिए यह चरण छोड़ दें, और यूज़र का नाम और पासवर्ड हाथ में रखें।

2. Status200 में कनेक्शन जोड़ें#

   उत्पाद → Security Events → Connections (/dashboard/{projectId}/security-events/connections) खोलें, कनेक्शन जोड़ें पर क्लिक करें, Splunk Enterprise Security चुनें, और अगला पर क्लिक करें। नीचे दी गई तालिका की सेटिंग्स भरें, अगला पर क्लिक करें, और टोकन को Authentication token में, या पासवर्ड को पासवर्ड में पेस्ट करें।

3. सहेजने से पहले इसे टेस्ट करें#

   सहेजने से पहले टेस्ट करें के नीचे Test these settings पर क्लिक करें। टेस्ट फ़ॉर्म के मानों से ऑथेंटिकेट करता है और आपकी सर्च चलाता है, और कुछ नहीं सहेजता, इसलिए गलत पोर्ट या कोई छूटा हुआ रोल कनेक्शन बनने से पहले ही सामने आ जाता है। फिर अगला पर क्लिक करें, कनेक्शन को एक नाम दें, और उसे बनाएं।

Authentication token और पासवर्ड एन्क्रिप्ट किए जाते हैं, API उन्हें कभी नहीं लौटाता, और वे फिर कभी नहीं दिखते। किसी एक को बदलने के लिए कनेक्शन पर Update credentials इस्तेमाल करें। एक ऑथेंटिकेशन से दूसरे पर जाने के लिए, वहां नया डालें और Remove the stored Authentication token या Remove the stored Password चालू करें।

Polling चरण में एक वैकल्पिक विवरण, Poll Interval (Minutes), जो 1 से 1440 तक की पूर्ण संख्या है और 5 से शुरू होती है, और सक्षम भी है, जो शुरू में चालू रहता है।

क्या इम्पोर्ट होता है#

सर्च से लौटी हर पंक्ति एक Detection Finding इवेंट (OCSF क्लास 2004) बनती है, जिसका वेंडर Splunk और प्रोडक्ट Splunk Enterprise Security होता है। एक notable event के लिए:

किसी दूसरे इंडेक्स की पंक्ति भी इसी तरह इम्पोर्ट होती है। जो कॉलम उसके फ़ील्ड नहीं भरते वे खाली रहते हैं, और हर फ़ील्ड attributes में खोजने लायक बना रहता है।

पोलिंग कैसे काम करती है#

हर पोल अपनी विंडो पर, सबसे पुराने पहले, एक एक्सपोर्ट सर्च चलाता है:

POST {Splunk management URL}/services/search/v2/jobs/export
    search=search index=notable | fields * | sort 0 _time | head 10001
    earliest_time={window start}
    latest_time={window end}
    output_mode=json

• बनने का समय ही कर्सर है। विंडो _time पर होती है, जो notable event के लिए वह समय है जब कोरिलेशन सर्च ने उसे बनाया, न कि वह जब उसकी पाई गई गतिविधि हुई। हर घंटे चलने वाली सर्च अपने notable event पर अपने रन का समय लगाती है, इसलिए कोई भी कर्सर के पीछे नहीं छूटता।
• पहला पोल 24 घंटे पीछे देखता है, इसलिए नया कनेक्शन तुरंत अपने हाल के notable event दिखाता है।
• हर बाद वाला पोल सहेजे गए कर्सर से 1 मिनट पहले शुरू होता है, इसलिए दो विंडो की सीमा पर बनी पंक्ति कभी नहीं छूटती।
• एक पोल कर्सर से आगे ज़्यादा से ज़्यादा 24 घंटे पढ़ता है। जिस कनेक्शन का कर्सर पीछे रह गया, वह 24 घंटे की लगातार विंडो में बराबर आता है, और उसका Health Catching up दिखाता है।
• डुप्लिकेट event_id से, या Splunk के अपने _bkt और _cd से हटाए जाते हैं, प्रोजेक्ट के भीतर, इसलिए ओवरलैप, दोबारा कोशिश की गई विंडो और इम्पोर्ट कभी किसी पंक्ति को दो बार नहीं सहेजते।

9.0.1 से पुराना search head search/v2/jobs/export के अनुरोध पर 404 लौटाता है। तब Status200 इसे डेप्रिकेटेड search/jobs/export पर भेजता है, और रन एक चेतावनी में यह बताता है। search head को अपग्रेड करें: मौजूदा वर्शन उस एंडपॉइंट को बंद कर देते हैं।

जब किसी विंडो में एक पोल की क्षमता से ज़्यादा हो#

एक पोल ज़्यादा से ज़्यादा 10,000 पंक्तियां पढ़ता है। जब किसी विंडो में इससे ज़्यादा हों, तो रन Partial होता है, इस तरह की चेतावनी के साथ:

Stopped after collecting 10000 records; the window holds more. Records are read oldest first, and the last one read was created at 2026-09-14T08:12:44.000Z, where the next poll can resume.

सर्च विंडो को _time के हिसाब से, सबसे पुराने पहले, क्रम में रखती है, इसलिए Status200 कर्सर को पढ़ी गई आखिरी पंक्ति के बनने के समय पर ले जाता है, और अगला पोल उसी विंडो लंबाई के साथ वहीं से शुरू होता है। व्यस्त search head वही पंक्तियां दोबारा पढ़ने के बजाय हर पोल में 10,000 पंक्तियां पकड़ता है। उसी पल में बनी पंक्तियां दो बार पढ़ी जाती हैं, और डुप्लिकेट जांच दूसरी कॉपी हटा देती है। Splunk कोई भी पंक्ति लौटाने से पहले पूरी विंडो को क्रम में लगाता है, इसलिए खोजें में ऐसी सर्च जो ज़रूरत से कहीं ज़्यादा ढूंढती है, हर पोल को धीमा कर देती है। इसे सटीक रखें।

जब कोई रन सहेजे गए कर्सर से आगे बढ़ ही नहीं पाता, तो Status200 इसके बजाय विंडो छोटी करता है:

1. छोटा करें। अगला पोल उसी शुरुआती बिंदु से आधी लंबाई की विंडो पढ़ता है, और तब तक आधा करता रहता है जब तक कोई विंडो पूरी न पढ़ी जाए, कम से कम एक मिनट तक। रन की चेतावनी यही बताती है: This window holds more records than one poll can read; the next poll reads a {n} minute window from the same starting point.
2. वापस बढ़ाएं। किसी विंडो के पूरा पढ़े जाने के बाद अगली विंडो फिर दोगुनी होती है, ज़्यादा से ज़्यादा 24 घंटे तक।
3. एक मिनट से आगे बढ़ें। अगर एक मिनट में भी एक पोल की क्षमता से ज़्यादा हो, तो पोलिंग उससे आगे बढ़ जाती है, ताकि नए notable event आते रहें। रन Partial ही रहता है, और पिछली त्रुटि में More records were created in the one minute from {cursor} to {end} than one poll can read. Polling moved past this minute so newer records keep arriving; use Import this time range in Diagnostics on this minute to recover what one run can read. लिखा होता है। एक रन जितना पढ़ सकता है उतना वापस पाने के लिए उस मिनट को Import this time range से इम्पोर्ट करें।

जो रन Splunk की किसी त्रुटि से पूरी तरह विफल होता है, वह कर्सर और विंडो लंबाई नहीं बदलता, और अगला पोल वही विंडो फिर से पढ़ता है। एकमात्र अपवाद वह अनुरोध है जिसका समय खत्म हो गया: कर्सर वहीं रहता है, लेकिन अगली विंडो आधी लंबी होती है, क्योंकि जो विंडो समय पर जवाब पाने के लिए बहुत भारी हो, वह हर कोशिश में टाइम आउट होगी। Poll Interval (Minutes) बदलने से इसमें कुछ नहीं बदलता: यह तय करता है कि पोल कितनी बार शुरू होता है, न कि उसकी विंडो कहां से शुरू होती है।

मांग पर रन, प्रीव्यू और इम्पोर्ट#

किसी कनेक्शन पर Diagnostics पर क्लिक करें, ताकि उसके हाल के रन देख सकें और उसके साथ हाथ से काम कर सकें। जो भी कनेक्शन बदल सकता है वह इन्हें शुरू कर सकता है; जो भी इसे देख सकता है वह इतिहास पढ़ सकता है।

• Run now तुरंत सामान्य कर्सर के साथ एक पोल शुरू करता है, तब भी जब कनेक्शन सक्षम न हो।
• Preview notable events 7 दिन तक की समय सीमा पढ़ता है और कुछ इम्पोर्ट नहीं करता।
• Import this time range आपकी पुष्टि के बाद 7 दिन तक की सीमा इम्पोर्ट करता है, कर्सर हिलाए बिना। पहले से इम्पोर्ट की गई पंक्तियां छोड़ दी जाती हैं।
• किसी रन पर Copy diagnostics सपोर्ट के लिए उसकी रिपोर्ट कॉपी करता है। इसमें क्रेडेंशियल कभी शामिल नहीं होते।

कनेक्शन का परीक्षण करें#

कनेक्शन की पंक्ति पर कनेक्शन का परीक्षण करें, और फ़ॉर्म में Test these settings, बैकग्राउंड वर्कर में नहीं बल्कि API प्रोसेस में चलते हैं, इसलिए जब वर्कर ही समस्या हों तब भी टेस्ट जवाब देता है। यह ये जांचें क्रम से चलाता है:

टेस्ट के हर अनुरोध की समय सीमा 20 सेकंड है। टेस्ट कभी कुछ इम्पोर्ट नहीं करता और न कर्सर हिलाता है, और हर विफल जांच बताती है कि क्या बदलना है।

Splunk को सुरक्षा इवेंट भेजें#

Status200 जो पाता है उसे Splunk के HTTP Event Collector (HEC) के ज़रिए Splunk को भी भेज सकता है, ताकि आपकी खोजें और डैशबोर्ड आपके अपने डिटेक्शन के साथ Status200 के डिटेक्शन भी देखें। हर सुरक्षा इवेंट sourcetype status200:security वाला एक HEC इवेंट होता है, और उसके फ़ील्ड के नाम वही होते हैं जो Splunk का Common Information Model रखता है: src, src_ip, src_user, dest, dest_ip, dest_port, user, signature और severity।

1. HEC टोकन बनाएँ#

   Splunk Web में Settings → Data inputs → HTTP Event Collector खोलें और New Token पर क्लिक करें। उसे नाम दें, वे इंडेक्स चुनें जिनमें वह लिख सकता है और उसका डिफ़ॉल्ट इंडेक्स, और टोकन का मान कॉपी करें। Splunk Cloud पर HEC https://http-inputs-<stack>.splunkcloud.com पर सुनता है; Splunk Enterprise पर, Global Settings में टोकन चालू होने के बाद पोर्ट 8088 पर।

2. गंतव्य जोड़ें#

   उत्पाद → Security Events → Connections खोलें। अपने SIEM में भेजें के नीचे गंतव्य जोड़ें पर क्लिक करें, SIEM में Splunk चुनें और अगला पर क्लिक करें। HEC URL भरें और टोकन को HEC टोकन में चिपकाएँ। Index और स्रोत प्रकार वैकल्पिक हैं: खाली छोड़ने पर इवेंट टोकन के डिफ़ॉल्ट इंडेक्स में sourcetype status200:security के साथ जाते हैं।

3. टेस्ट इवेंट भेजें और भेजना शुरू करें#

   टेस्ट इवेंट भेजें पर क्लिक करें: फ़ॉर्म की सेटिंग के साथ एक सूचनात्मक इवेंट Splunk को जाता है, और कुछ भी सहेजा नहीं जाता। उसे sourcetype="status200:security" से खोजें। फिर क्या भेजना है में सिर्फ़ डिटेक्शन रहने दें या सभी सुरक्षा इवेंट चुनें, और भेजना शुरू करें पर क्लिक करें।

• HEC URL को https इस्तेमाल करना होगा, ऐसे सर्टिफ़िकेट के साथ जिस पर Status200 भरोसा करता है: सर्टिफ़िकेट जाँच कभी नहीं छोड़ी जाती।
• इवेंट 500 तक के बैच में जाते हैं। जिस इवेंट को Splunk अस्वीकार करता है, उसे छोड़ दिया जाता है और त्रुटि देखें में बताया जाता है, व्यस्त कलेक्टर (503) को फिर आज़माया जाता है, और अस्वीकार किया गया टोकन या इंडेक्स तब तक भेजना रोक देता है जब तक आप उसे ठीक न करें।
• Status200 ने Splunk से जो notable event इम्पोर्ट किए हैं, वे कभी वापस Splunk को नहीं भेजे जाते।

समस्या निवारण#

कनेक्शन का पिछली त्रुटि पूरा त्रुटि संदेश रखता है, क्रेडेंशियल छिपाकर, एक ऐसे प्रीफ़िक्स के पीछे जो विफल हुए चरण का नाम बताता है। जब किसी कनेक्शन में त्रुटि हो, तो उसे पढ़ने के लिए उसके क्रियाएँ कॉलम में त्रुटि देखें चुनें, और कॉपी करने के लिए डायलॉग में त्रुटि कॉपी करें। पहले प्रीफ़िक्स पढ़ें।

आपको क्या मिलता है#

• खोज। सुरक्षा इवेंट एक्सप्लोरर में, हर दूसरे स्रोत के साथ, notable event को अर्जेंसी, स्थिति, नियम, यूज़र, होस्ट या किसी भी observable से फ़िल्टर करें।
• सहसंबंध। हर पंक्ति के यूज़र, होस्ट, IP और डोमेन observable के रूप में इंडेक्स होते हैं, इसलिए एक सर्च उन सबको ढूंढ लेती है जो उनका ज़िक्र करते हैं।
• पहचान नियम। Sigma नियम जो शेड्यूल पर आपके सुरक्षा इवेंट पर चलते हैं, और ऑन-कॉल को पेज करने वाले अलर्ट खोलते हैं।
• मॉनिटर। सुरक्षा इवेंट मॉनिटर मेल खाने वाले इवेंट गिनते हैं, जैसे नए गंभीर notable event, और थ्रेशोल्ड पार होने पर घटनाएं या अलर्ट खोलते हैं।

सुरक्षा इवेंट का बिल आपकी बाकी टेलीमेट्री की तरह, इंजेस्ट किए गए हर GB के हिसाब से बनता है। मूल्य निर्धारण देखें।

अगले कदम#