Suricata

परिचय

Suricata एक नेटवर्क IDS, IPS और NSM इंजन है जिसे OISF और Suricata समुदाय द्वारा विकसित किया गया है।

संसाधन

योगदान

हम खुशी-खुशी पैच और अन्य योगदान स्वीकार करते हैं। आरंभ करने के तरीके के लिए कृपया हमारी योगदान प्रक्रिया देखें।

Suricata एक जटिल सॉफ़्टवेयर है जो अधिकतर अविश्वसनीय इनपुट से निपटता है। इस इनपुट का गलत प्रबंधन गंभीर परिणाम दे सकता है:

IPS मोड में क्रैश किसी नेटवर्क को ऑफ़लाइन कर सकता है
पैसिव मोड में IDS से समझौता होने पर महत्वपूर्ण और गोपनीय डेटा की हानि हो सकती है
पता लगाने में चूक से नेटवर्क का बिना पता चले समझौता हो सकता है

दूसरे शब्दों में, हमें लगता है कि दांव काफी ऊँचे हैं, खासकर क्योंकि कई सामान्य मामलों में IDS/IPS सीधे किसी हमलावर की पहुँच में होगा।

इस कारण से, हमने एक काफी व्यापक QA प्रक्रिया विकसित की है। इसका परिणाम यह है कि Suricata में योगदान देना कुछ लंबी प्रक्रिया हो सकती है।

उच्च स्तर पर, चरण इस प्रकार हैं:

GitHub-CI आधारित जाँचें। यह पुल अनुरोध (pull request) बनाए जाने पर स्वचालित रूप से चलती हैं।
टीम और समुदाय के डेवलपर्स द्वारा समीक्षा
निजी QA सेटअपों से QA रन। परीक्षण ट्रैफ़िक की प्रकृति के कारण ये निजी हैं।

Suricata के QA चरणों का अवलोकन

OISF टीम के सदस्य हमारे निजी QA सेटअप में बिल्ड सबमिट कर सकते हैं। यह बिल्ड परीक्षणों की एक श्रृंखला और एक रिग्रेशन सूट चलाएगा ताकि यह पुष्टि हो सके कि कोई मौजूदा सुविधा न टूटे।

अंतिम QA रन में न्यूनतम कुछ घंटे लगते हैं, और आम तौर पर रात भर चलता है। यह वर्तमान में निम्नलिखित चलाता है:

विभिन्न OS, कंपाइलर, ऑप्टिमाइज़ेशन स्तरों और configure फीचर्स पर व्यापक बिल्ड परीक्षण
cppcheck, scan-build का उपयोग करके स्टैटिक कोड विश्लेषण
valgrind, AddressSanitizer, LeakSanitizer का उपयोग करके रनटाइम कोड विश्लेषण
पिछले बग्स के लिए रिग्रेशन परीक्षण
लॉगिंग के आउटपुट का सत्यापन
यूनिक्स सॉकेट परीक्षण
ASAN और LSAN का उपयोग करके pcap आधारित फ़ज़ परीक्षण
ट्रैफ़िक रीप्ले आधारित IDS और IPS परीक्षण

इन परीक्षणों के अलावा, कोड परिवर्तन के प्रकार के आधार पर आगे के परीक्षण मैन्युअल रूप से चलाए जा सकते हैं:

ट्रैफ़िक रीप्ले परीक्षण (मल्टी-गीगाबिट)
बड़े pcap संग्रह का प्रसंस्करण (मल्टी-टेराबाइट्स)
फ़ज़ परीक्षण (कई दिन या सप्ताह भी लग सकते हैं)
pcap आधारित प्रदर्शन परीक्षण
लाइव प्रदर्शन परीक्षण
प्रस्तावित परिवर्तनों के मूल्यांकन के आधार पर विभिन्न अन्य मैन्युअल परीक्षण

यह समझना महत्वपूर्ण है कि उपरोक्त लगभग सभी परीक्षण स्वीकृति परीक्षणों के रूप में उपयोग किए जाते हैं। यदि कुछ विफल होता है, तो इसे अपने कोड में संबोधित करना आप पर निर्भर है।

QA का एक चरण वर्तमान में मर्ज के बाद चलाया जाता है। हम Coverity Scan प्रोग्राम में बिल्ड सबमिट करते हैं। इस (मुफ़्त) सेवा की सीमाओं के कारण, हम अधिकतम दिन में एक बार सबमिट कर सकते हैं। निश्चित रूप से ऐसा हो सकता है कि मर्ज के बाद समुदाय को समस्याएँ मिलें। दोनों ही मामलों में, हम आपसे अनुरोध करते हैं कि जैसे-जैसे समस्याएँ सामने आएँ, उन्हें हल करने में सहायता करें।

अक्सर पूछे जाने वाले प्रश्न (FAQ)

Q: क्या आप मेरा PR स्वीकार करेंगे?

A: यह कई चीजों पर निर्भर करता है, जिसमें कोड की गुणवत्ता भी शामिल है। नई सुविधाओं के साथ यह इस बात पर भी निर्भर करता है कि टीम और/या समुदाय सुविधा को उपयोगी मानते हैं या नहीं, यह अन्य कोड और सुविधाओं को कितना प्रभावित करती है, प्रदर्शन रिग्रेशन का जोखिम आदि।

Q: मेरा PR कब मर्ज किया जाएगा?

A: यह निर्भर करता है। यदि यह एक प्रमुख सुविधा है या उच्च जोखिम वाला परिवर्तन माना जाता है, तो यह संभवतः अगले प्रमुख संस्करण में शामिल होगा।

Q: मेरा PR क्यों बंद किया गया?

A: जैसा कि Suricata GitHub workflow में प्रलेखित है, हम हर परिवर्तन के लिए एक नए pull request की अपेक्षा करते हैं।

आम तौर पर, टीम (या समुदाय) एक pull request पर प्रतिक्रिया देगी, जिसके बाद इसे बेहतर PR द्वारा प्रतिस्थापित किए जाने की अपेक्षा की जाती है। इसलिए टिप्पणियों को देखें। यदि आप टिप्पणियों से असहमत हैं, तो हम बंद PR में उन पर चर्चा कर सकते हैं।

यदि PR बिना टिप्पणियों के बंद किया गया था, तो यह संभवतः QA विफलता के कारण है। यदि GitHub-CI जाँचें विफल रहीं, तो PR को तुरंत ठीक किया जाना चाहिए। इसके बारे में चर्चा करने की आवश्यकता नहीं है, जब तक कि आपको न लगे कि QA विफलता गलत है।

Q: कंपाइलर/कोड विश्लेषक/टूल गलत है, अब क्या?

A: QA के स्वचालन में सहायता के लिए, हम चेतावनियों या त्रुटियों को बने रहने की अनुमति नहीं देते। कुछ मामलों में इसका मतलब यह हो सकता है कि यदि टूल उसका समर्थन करता है (जैसे valgrind, DrMemory) तो हम एक सप्रेशन जोड़ दें। कुछ चेतावनियों को अक्षम किया जा सकता है। कुछ असाधारण मामलों में एकमात्र 'समाधान' कोड को रीफैक्टर करना है ताकि स्टैटिक कोड चेकर की सीमा (false positive) के आसपास काम किया जा सके। निराशाजनक होते हुए भी, हम आउटपुट में चेतावनियाँ छोड़ने की तुलना में इसे प्राथमिकता देते हैं। चेतावनियों को अनदेखा किए जाने की प्रवृत्ति होती है और फिर अन्य चेतावनियों को छिपाने का जोखिम बढ़ जाता है।

Q: मुझे लगता है कि आपका QA परीक्षण गलत है

A: यदि आप वास्तव में ऐसा सोचते हैं, तो हम इसे बेहतर बनाने के तरीके पर चर्चा कर सकते हैं। लेकिन इस निष्कर्ष पर बहुत जल्दी न पहुँचें, अक्सर कोड ही गलत निकलता है।

Q: क्या आपको योगदानकर्ता लाइसेंस समझौते पर हस्ताक्षर करने की आवश्यकता है?

A: हाँ, हम Suricata के स्वामित्व को एक ही हाथ में रखने के लिए ऐसा करते हैं: Open Information Security Foundation। देखें http://suricata.io/about/open-source/ और http://suricata.io/about/contribution-agreement/

suricata suricata-8.0.7

श्रेणियाँ