Libmodsecurity, ModSecurity v3 परियोजना का एक घटक है। लाइब्रेरी कोडबेस ModSecurity कनेक्टरों के लिए एक इंटरफ़ेस के रूप में कार्य करता है, जो वेब ट्रैफ़िक लेता है और पारंपरिक ModSecurity प्रसंस्करण लागू करता है। सामान्य तौर पर, यह ModSecurity SecRules प्रारूप में लिखे गए नियमों को लोड/इंटरप्रेट करने और उन्हें आपके एप्लिकेशन द्वारा कनेक्टरों के माध्यम से प्रदान की गई 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) है। इस लाइब्रेरी का उपभोग उन 'कनेक्टरों' द्वारा किया जाता है जिन्हें हम 'कनेक्टर' कहते हैं, ये कनेक्टर आपके वेबसर्वर के साथ इंटरफ़ेस करेंगे और लाइब्रेरी को एक सामान्य प्रारूप प्रदान करेंगे जिसे वह समझता है। इनमें से प्रत्येक कनेक्टर को एक अलग GitHub प्रोजेक्ट के रूप में बनाए रखा जाता है। उदाहरण के लिए, Nginx कनेक्टर ModSecurity-nginx प्रोजेक्ट (https://github.com/owasp-modsecurity/ModSecurity-nginx) द्वारा प्रदान किया जाता है।

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

संकलन

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

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

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

Unix (Linux, macOS, FreeBSD, …)

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

यदि आप git चेकआउट के साथ काम कर रहे हैं, तो निर्माण करने से पहले रिपॉजिटरी को पुनरावर्ती रूप से क्लोन करना या सभी उपमॉड्यूल को प्रारंभ करना सुनिश्चित करें।
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

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

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 का पता लगाया और उपयोग किया जाता है।
  • फ़ॉलबैक: लीगेसी PCRE का उपयोग किया जा सकता है यदि --with-pcre स्पष्ट रूप से प्रदान किया गया हो (WITH_PCRE)।

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

अन्य सभी निर्भरताएँ SecRules के भीतर निर्दिष्ट ऑपरेटरों या कॉन्फ़िगरेशन निर्देशों से संबंधित हैं और संकलन के लिए आवश्यक नहीं हो सकती हैं।

ऑपरेटर-संबंधित निर्भरताएँ

• libinjection ऑपरेटरों @detectXSS और @detectSQL के लिए आवश्यक है।
• curl निर्देश SecRemoteRules के लिए आवश्यक है।

यदि वे लाइब्रेरी गायब हैं, तो ModSecurity संबंधित ऑपरेटरों या निर्देशों के समर्थन के बिना संकलित किया जाएगा।

Git-उपमॉड्यूल

रिपॉजिटरी में निम्नलिखित उपमॉड्यूल शामिल हैं:

• others/libinjection – @detectSQLi और @detectXSS ऑपरेटरों द्वारा उपयोग किया जाता है।

• others/mbedtls (TF-PSA-Crypto सबसेट) – क्रिप्टोग्राफ़िक फ़ंक्शन और सहायकों (जैसे हैशिंग, बेस64) के लिए उपयोग किया जाता है।

  ध्यान दें: नया mbedTLS v4 लेआउट पुराने v3 संरचना के साथ संगत नहीं है। आंतरिक संरचना में काफी बदलाव आया है, और कई घटकों को उपमॉड्यूल (जैसे TF-PSA-Crypto) में स्थानांतरित कर दिया गया है।

  PR #3532 को मर्ज करने के बाद, चलाना आवश्यक है:

  git submodule update --init --recursive