Libmodsecurity, ModSecurity v3 प्रोजेक्ट का एक घटक है। यह लाइब्रेरी कोडबेस ModSecurity Connectors के लिए एक इंटरफ़ेस का कार्य करता है, जो वेब ट्रैफ़िक लेता है और पारंपरिक ModSecurity प्रोसेसिंग लागू करता है। सामान्य तौर पर, यह ModSecurity SecRules प्रारूप में लिखे गए नियमों को लोड/व्याख्या करने और उन्हें Connectors के माध्यम से आपके एप्लिकेशन द्वारा प्रदान की गई HTTP सामग्री पर लागू करने की क्षमता प्रदान करता है।

यदि आप Apache के लिए ModSecurity (जिसे ModSecurity v2.x भी कहा जाता है) खोज रहे हैं, तो यह अभी भी रखरखाव में है और उपलब्ध है: यहाँ।

इस प्रोजेक्ट और पुराने ModSecurity (v2.x.x) के बीच क्या अंतर है?

• सभी Apache निर्भरताएँ हटा दी गई हैं
• उच्च प्रदर्शन
• नई सुविधाएँ
• नई आर्किटेक्चर

Libmodsecurity, ModSecurity प्लेटफ़ॉर्म का पूर्ण पुनर्लेखन है। जब इसे पहली बार परिकल्पित किया गया था, तब ModSecurity प्रोजेक्ट केवल एक Apache मॉड्यूल के रूप में शुरू हुआ था। समय के साथ, लोकप्रिय मांग के कारण, प्रोजेक्ट का विस्तार अन्य प्लेटफ़ॉर्मों को सहायता प्रदान करने के लिए किया गया, जिनमें (लेकिन इन्हीं तक सीमित नहीं) Nginx और IIS शामिल हैं। अतिरिक्त प्लेटफ़ॉर्म समर्थन की बढ़ती मांग को पूरा करने के लिए, इस प्रोजेक्ट के अंतर्निहित Apache निर्भरताओं को हटाना आवश्यक हो गया, जिससे यह अधिक प्लेटफ़ॉर्म-स्वतंत्र हो गया।

इस लक्ष्य के परिणामस्वरूप हमने Libmodsecurity को इस तरह से पुनर्गठित किया है कि यह अब Apache वेब सर्वर पर निर्भर नहीं है (न तो संकलन के समय और न ही रनटाइम के दौरान)। इसका एक साइड इफ़ेक्ट यह है कि सभी प्लेटफ़ॉर्मों पर उपयोगकर्ता बेहतर प्रदर्शन की अपेक्षा कर सकते हैं। इसके अतिरिक्त, हमने इस अवसर का उपयोग कुछ नई सुविधाओं की नींव रखने के लिए किया है जिनकी उपयोगकर्ता लंबे समय से चाह रहे थे। उदाहरण के लिए, हम भविष्य के संस्करणों में JSON प्रारूप में ऑडिटलॉग्स के मूल समर्थन के साथ-साथ कई अन्य कार्यक्षमताओं को शामिल करने की योजना बना रहे हैं।

यह अब केवल एक मॉड्यूल नहीं है।

'ModSecurity' ब्रांच में अब पारंपरिक मॉड्यूल लॉजिक (Nginx, Apache और IIS के लिए) नहीं है जिसे पारंपरिक रूप से एक साथ पैकेज किया जाता था। इसके बजाय, इस ब्रांच में इस प्रोजेक्ट के लिए केवल लाइब्रेरी भाग (libmodsecurity) है। इस लाइब्रेरी का उपभोग वह करता है जिसे हम 'Connectors' कहते हैं; ये कनेक्टर आपके वेबसर्वर के साथ इंटरफ़ेस करेंगे और लाइब्रेरी को एक सामान्य प्रारूप प्रदान करेंगे जिसे वह समझती है। इनमें से प्रत्येक कनेक्टर को एक अलग GitHub प्रोजेक्ट के रूप में बनाए रखा जाता है। उदाहरण के लिए, Nginx कनेक्टर ModSecurity-nginx प्रोजेक्ट (https://github.com/owasp-modsecurity/ModSecurity-nginx) द्वारा प्रदान किया जाता है।

इन कनेक्टर्स को अलग रखने से प्रत्येक प्रोजेक्ट को अलग रिलीज़ चक्र, इश्यू और डेवलपमेंट ट्री रखने की सुविधा मिलती है। इसके अतिरिक्त, इसका मतलब है कि जब आप ModSecurity v3 इंस्टॉल करते हैं तो आपको बिल्कुल वही मिलता है जिसकी आपको आवश्यकता है, कोई अतिरिक्त चीज़ नहीं जिसका आप उपयोग नहीं करेंगे।

संकलन

संकलन प्रक्रिया शुरू करने से पहले, सुनिश्चित करें कि सभी आवश्यक निर्भरताएँ स्थापित हैं।
अधिक जानकारी के लिए निर्भरताएँ और Git सबमॉड्यूल अनुभाग देखें।

संकलन के बाद, सुनिश्चित करें कि आपके बिल्ड/प्लेटफ़ॉर्म पर कोई समस्या नहीं है।
हम यूनिट परीक्षण और रिग्रेशन परीक्षण चलाने की दृढ़ता से अनुशंसा करते हैं। ये परीक्षण उपयोगिताएँ tests/ सबफ़ोल्डर में स्थित हैं।

एक डायनामिक लाइब्रेरी के रूप में, libmodsecurity को ऐसे स्थान पर स्थापित किया जाना चाहिए जहाँ आपका ऑपरेटिंग सिस्टम डायनामिक लाइब्रेरीज़ ढूँढ सके।

Unix (Linux, macOS, FreeBSD, …)

Unix-जैसे सिस्टम पर, प्रोजेक्ट संकलन प्रक्रिया के लिए autotools का उपयोग करता है।

यदि आप git checkout के साथ काम कर रहे हैं, तो बिल्ड करने से पहले रिपॉज़िटरी को पुनरावर्ती रूप से क्लोन करना या सभी सबमॉड्यूल प्रारंभ करना सुनिश्चित करें।
Git सबमॉड्यूल अनुभाग भी देखें।

git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity

यह रिपॉज़िटरी git सबमॉड्यूल का उपयोग करती है। क्लोन करने के बाद, सभी सबमॉड्यूल को इनिशियलाइज़ और फ़ेच करना सुनिश्चित करें:

git submodule update --init --recursive

आप यह सत्यापित कर सकते हैं कि सभी सबमॉड्यूल ठीक से आरंभ किए गए हैं:

git submodule status

जो सबमॉड्यूल सही ढंग से इनिशियलाइज़ किए गए हैं, वे एक कमिट हैश दिखाते हैं। शुरुआत में - यह दर्शाता है कि सबमॉड्यूल इनिशियलाइज़ नहीं किया गया है।

इसके बाद आप बिल्ड प्रक्रिया शुरू कर सकते हैं:

./build.sh
./configure
make
sudo make install

वितरण-विशिष्ट बिल्ड के विवरण हमारे Wiki में पाए जा सकते हैं: Compilation Recipes

Windows

Windows बिल्ड जानकारी यहाँ पाई जा सकती है।

निर्भरताएँ

• यह लाइब्रेरी C++17 मानक का उपयोग करते हुए C++ में लिखी गई है।
• यह "Sec Rules Language" पार्सर बनाने के लिए Flex और Bison (Yacc) का उपयोग करती है।
• अनिवार्य निर्भरताओं में YAJL शामिल है, क्योंकि ModSecurity लॉगिंग और अपने परीक्षण ढाँचे के लिए JSON का उपयोग करता है।
• libXML2 (वैकल्पिक) का उपयोग XML अनुरोधों को पार्स करने के लिए किया जाता है।

रेगुलर एक्सप्रेशन इंजन (PCRE2 / PCRE)

• SecRules में रेगुलर एक्सप्रेशन प्रोसेसिंग Regex यूटिलिटी (src/utils/regex.*) के माध्यम से लागू की जाती है।

• डिफ़ॉल्ट रूप से, ModSecurity रेगेक्स हैंडलिंग के लिए PCRE2 का उपयोग करता है।

• इसका उपयोग @rx, @rxGlobal, और @verifyCC जैसे ऑपरेटरों द्वारा किया जाता है।

• बिल्ड-टाइम व्यवहार:

  • डिफ़ॉल्ट: PCRE2 का पता लगाया जाता है और उसका उपयोग किया जाता है।
  • फ़ॉलबैक: यदि --with-pcre स्पष्ट रूप से प्रदान किया जाए (WITH_PCRE) तो लीगेसी PCRE का उपयोग किया जा सकता है।

• दूसरे शब्दों में, वर्तमान बिल्ड PCRE2 की अपेक्षा करते हैं जब तक कि स्पष्ट रूप से अन्यथा कॉन्फ़िगर न किया जाए।

• @rx और @rxGlobal डिफ़ॉल्ट रूप से DOTALL | MULTILINE के साथ पैटर्न संकलित करते हैं: DOTALL . को न्यूलाइन से मिलान करने देता है, और MULTILINE ^/$ को केवल पूरे विषय के आरंभ/अंत के बजाय प्रत्येक आंतरिक लाइन ब्रेक पर एंकर करने देता है। उन्हें DOTALL | DOLLAR_ENDONLY के साथ संकलित करने के लिए --enable-regex-dollar-endonly=yes पास करें: MULTILINE के बिना, ^/$ केवल पूरे विषय के आरंभ/अंत पर एंकर होते हैं, और DOLLAR_ENDONLY $ को केवल वहीं मिलान करने तक सीमित करता है, न कि ट्रेलिंग न्यूलाइन से ठीक पहले भी। DOTALL किसी भी स्थिति में अपरिवर्तित रहता है, इसलिए पैटर्न अभी भी . के माध्यम से आंतरिक लाइन ब्रेक्स के पार मिलान कर सकते हैं। यह ModSecurity v2 के @rx व्यवहार से मेल खाता है। यह फ़्लैग डिफ़ॉल्ट रूप से अक्षम है; देखें issue #3295।