मल्टी-साइट होस्टिंग - महत्वपूर्ण भेद्यता एक दूसरे से सुरक्षित साइटों को याद किया जा रहा है?

Question

EDIT # 2 जुलाई 23, 2015: एक नए उत्तर की तलाश में है जो नीचे के सेटअप में याद किए गए एक महत्वपूर्ण सुरक्षा आइटम की पहचान करता है या सब कुछ कवर करने पर विश्वास करने का कारण दे सकता है।

EDIT # 3 जुलाई 29, 2015: मैं विशेष रूप से एक संभावित गलतफहमी के लिए देख रहा हूं जैसे कि अनजाने में कुछ ऐसी चीजों की अनुमति देना जो सुरक्षा प्रतिबंधों को कम करने के लिए शोषण किया जा सकता है या अभी तक कुछ व्यापक रूप से खुला छोड़ सकता है।

यह बहु-साइट / साझा होस्टिंग सेटअप है और हम एक साझा अपाचे उदाहरण (यानी एक उपयोगकर्ता खाते के तहत चलाता है) का उपयोग करना चाहते हैं, लेकिन PHP / CGI प्रत्येक वेबसाइट के उपयोगकर्ता के रूप में चल रहा है ताकि यह सुनिश्चित किया जा सके कि कोई साइट किसी अन्य साइट की फ़ाइलों तक नहीं पहुंच सकती है, और हम चाहते हैं यह सुनिश्चित करें कि कुछ भी याद नहीं किया जा रहा है (जैसे कि अगर हम सिमलिंक अटैक की रोकथाम के बारे में नहीं जानते हैं)।

यहाँ मेरे पास अभी तक क्या है:

• सुनिश्चित करें कि PHP स्क्रिप्ट वेबसाइट के लिनक्स उपयोगकर्ता खाते और समूह के रूप में चलती है, और या तो जेल (जैसे CageFS का उपयोग कर) या लिनक्स फाइल सिस्टम अनुमतियों का उपयोग करके कम से कम ठीक से प्रतिबंधित है।
• यह सुनिश्चित करने के लिए suexec का उपयोग करें कि CGI लिपियों को Apache उपयोगकर्ता के रूप में नहीं चलाया जा सकता है।
• यदि सर्वर-साइड की आवश्यकता में समर्थन शामिल है (जैसे कि shtml फ़ाइलों में), Options IncludesNOEXECCGI को चलाने के लिए सक्षम होने से रोकने के लिए उपयोग करें जब आप इसकी अपेक्षा नहीं करते हैं (हालांकि यह suexec का उपयोग करते समय एक चिंता का विषय नहीं होना चाहिए)।
• एक जगह हैकर हमले से सुरक्षा कर सकते हैं ताकि एक हैकर एपाचे को किसी अन्य वेबसाइट की फाइलों को प्लेनटेक्स्ट के रूप में पेश न कर सके और डीबी पासवर्ड जैसी शोषणकारी जानकारी का खुलासा कर सके।
• कॉन्फ़िगर करें AllowOverride/ AllowOverrideListकेवल किसी भी निर्देश की अनुमति दें जो एक हैकर शोषण नहीं कर सकता है। मुझे लगता है कि यह एक चिंता का विषय है अगर उपरोक्त वस्तुओं को ठीक से किया जाता है।

अगर यह इतना धीमा नहीं होता और रूट के रूप में नहीं चलता, तो मैं MPM ITK के साथ जाता, लेकिन हम विशेष रूप से एक साझा Apache का उपयोग करना चाहते हैं, फिर भी सुनिश्चित करें कि यह सुरक्षित रूप से किया गया है।

मैंने http://httpd.apache.org/docs/2.4/misc/security_tips.html पाया , लेकिन यह इस विषय पर व्यापक नहीं था।

यदि यह जानना उपयोगी है, तो हम CageFS और mod_lsapi के साथ CloudLinux का उपयोग करने की योजना बना रहे हैं।

क्या इसके बारे में कुछ और सुनिश्चित करना है या जानना है?

EDIT 20 जुलाई 2015: लोगों ने कुछ अच्छे वैकल्पिक समाधान प्रस्तुत किए हैं जो सामान्य रूप से मूल्यवान हैं, लेकिन कृपया ध्यान दें कि यह प्रश्न केवल एक साझा अपाचे सेटअप की सुरक्षा के बारे में लक्षित है। विशेष रूप से ऐसा कुछ नहीं है, जो किसी साइट को किसी अन्य साइट की फ़ाइलों तक पहुँचने या अन्य साइटों को किसी भी तरह से समझौता करने दे सकता है?

धन्यवाद!

Comments

रुको तो आप हैं या आप शेल_सेक्स जैसे आदेशों को रोक नहीं रहे हैं

— माइकल बेली

या बल्कि कार्य करता है। आज्ञा नहीं।

— माइकल बेली

सही - हम उन आदेशों को रोक नहीं रहे हैं। क्योंकि CageFS PHP को इतनी अधिक मात्रा में अलग करता है, इस तरह के कमांड को गहराई के दृष्टिकोण में एक रक्षा के हिस्से के रूप में सीमित करने के लायक नहीं लगता है कि हम उन्हें कई बार वैध उद्देश्यों के लिए उपयोग करते हैं। यदि सर्वर हैकर्स के लिए एक उच्च मूल्य का लक्ष्य था (उदाहरण के लिए क्रेडिट कार्ड डेटा या ऐसा कुछ संग्रहीत), तो लाभ कमियां निकल सकती हैं, लेकिन हमारे मामले में मुझे नहीं लगता कि प्रतिबंध को वारंट किया गया है। यह निश्चित रूप से उन लोगों के लिए विचार करने योग्य है जो CageFS या कुछ समान समाधान का उपयोग नहीं कर रहे हैं।

— sa289

अफसोस की बात है कि आपने CPanel के कारण अच्छे उत्तर दिए हैं - बाकी इतिहास है।

— user9517

यहाँ उन उत्तरों के कारण हैं जिनके बारे में मैंने "छूट" दी है। प्रति साइट या डॉकटर कंटेनरों में समर्पित अपाचे - अधिक समर्पित सार्वजनिक आईपी या रिवर्स प्रॉक्सी की जटिलता की आवश्यकता होती है। सेलिनक्स - को लागू करने और मोड में सेलिनक्स को चलाने की आवश्यकता है। वीएम - एक गैर-वीएम सेटअप पर अतिरिक्त सिस्टम संसाधनों की आवश्यकता होती है। मुझे लगता है कि वे सभी अच्छे समाधान हैं, बस कमियां नहीं हैं जो मैं नहीं चाहता था।

— sa289

Answer 1

अब तक आपके पास मौजूद वस्तुओं से मैं पूरी तरह सहमत हूं।

मैं कुछ साल पहले ऐसा मल्टी-यूजर सेटअप चलाता था और मुझे मूल रूप से एक ही ट्रेड-ऑफ मिला: mod_php फास्ट (आंशिक रूप से क्योंकि सब कुछ उसी प्रक्रिया के अंदर चलता है) और suexec धीमा है लेकिन सुरक्षित है (क्योंकि हर अनुरोध एक नया प्रयास करता है प्रक्रिया)। मैं suexec के साथ गया था, क्योंकि उपयोगकर्ता अलगाव की आवश्यकता थी।

वर्तमान में एक तीसरा विकल्प है जिस पर आप विचार कर सकते हैं: प्रत्येक उपयोगकर्ता को अपने स्वयं के php-fpm डेमॉन दें। क्या यह संभव है, उपयोगकर्ताओं की संख्या पर निर्भर करता है, क्योंकि उनमें से प्रत्येक को अपने उपयोगकर्ता खाते का उपयोग करके कम से कम एक php-fpm प्रक्रिया प्राप्त करनी होती है (डेमॉन तब अनुरोधों के पैमाने के लिए तंत्र की तरह एक प्रीफ़ॉर्क का उपयोग करता है, इसलिए प्रक्रियाओं की संख्या उनकी स्मृति उपयोग कारकों को सीमित कर सकती है)। आपको कुछ स्वचालित कॉन्फ़िगरेशन पीढ़ी की भी आवश्यकता होगी, लेकिन कुछ शेल स्क्रिप्ट के साथ यह संभव होना चाहिए।

मैंने बड़े परिवेश में उस पद्धति का उपयोग नहीं किया है लेकिन IMHO जो कि प्रक्रिया स्तर पर उपयोगकर्ताओं को अलग करते हुए अच्छी PHP वेबसाइट प्रदर्शन प्रदान करने के लिए एक अच्छा समाधान है।

Comments

सही है अगर मैं गलत हूँ, लेकिन मुझे लगता है कि mod_lsapi + CageFS समाधान हम पहले से ही PHP के लिए साथ जाने की योजना बना रहे हैं कम से कम अच्छा है अगर PHP-FPM से बेहतर है, है ना? धन्यवाद

— sa289

मुझे mod_lsapi के साथ कोई अनुभव नहीं है और एक बंद स्रोत एकल विक्रेता समाधान पर भरोसा करने वाले आरक्षण होंगे। लेकिन इसके विज्ञापन पृष्ठ के अनुसार यह सिर्फ उतना ही अच्छा होना चाहिए और उतना ही तेज़, हाँ। - एक बिंदु पर मैं देखूंगा कि यह नई प्रक्रियाओं (नए अनुरोधों) पर कैसे लागू होता है और यह उपयोगकर्ता के लिए अपनी प्रभावी उपयोगकर्ता आईडी कैसे बदलता है। सुरक्षा के बारे में जो सबसे कमजोर बिंदु है; suexec प्रलेखन में चीजों की अच्छी व्याख्या है।

— मिसेचुएट

मुझे लगता है कि बंद या खुले स्रोत पर भरोसा करने का कोई कारण नहीं है हे (शेलशॉक को खोजने में 25 साल लगे, हार्टलेड 2 साल, और जो ट्रूक्रिप्ट के बारे में जानता है)। सौभाग्य से मुझे लगता है कि mod_lsapi लाइटस्पीड के ओपन सोर्स ऑफर के आसपास आधारित है, इसलिए कम से कम कुछ विक्रेताओं में से कुछ को देख रहे हैं, साथ ही जो कोई भी उस पर आधारित ओपन सोर्स कोड को देखना चाहता है। मैं विशेष रूप से किसी भी महत्वपूर्ण सुरक्षा चीजों की तलाश कर रहा हूं जो मुझे प्रस्तावित सेटअप में गुम हो सकता है (जैसे कि PHP साइट के उपयोगकर्ता के रूप में चलने के लिए लेकिन CGI लिपियों के लिए suEXEC के बारे में भूल जाना)। धन्यवाद

— sa289

हम इस दृष्टिकोण (php-fpm के साथ वेबसर्वर) का उपयोग बहुत बड़े पैमाने पर वेबसाइटों पर कर रहे हैं (जहाँ वेबसर्वर फ़ार्म php-fpm फ़ार्म को एक लोड-बॉलर के माध्यम से जोड़ता है)। ऐसे कॉन्फ़िगरेशन की सुंदरता जिसे वर्चुअल होस्ट ओएस स्तर पर अलग किया जाता है और उस सीमा को आसानी से दरकिनार नहीं किया जाता है (बस यह सुनिश्चित करें कि वर्चुअल होस्ट की होम डायरेक्टरी में 0710 जैसी अनुमतियाँ हैं जो vhost उपयोगकर्ता के स्वामित्व और वेबसर्वर प्रक्रिया के समूह के साथ हैं। , तो यह उचित अनुमतियों की बात है - अगर एक फ़ाइल दुनिया पठनीय यह वेबसर्वर के लिए सुलभ होगी)

— आकाशगंगा

Answer 2

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

मेरा सुझाव होगा कि प्रत्येक साइट को स्वयं का ओएस जेल देने के लिए किसी प्रकार के VM सॉफ़्टवेयर (VMware, VirtualBox, Qemu, आदि) का उपयोग किया जाए। यह आपको सिस्टम प्रशासक के रूप में, एक भी समझौता साइट के बारे में चिंता न करने की अनुमति देता है। यदि किसी हैकर ने किसी साइट के VM पर php (या किसी अन्य सॉफ़्टवेयर) का शोषण करके रूट प्राप्त किया है, तो VM को विराम दें और बाद में इसे विच्छेदित करें, फ़िक्सेस लागू करें, या अखंड स्थिति में वापस रोल करें। यह साइट व्यवस्थापक को उनके विशिष्ट साइट वातावरण (जो किसी अन्य साइट को तोड़ सकता है) के लिए विशिष्ट सॉफ़्टवेयर या सुरक्षा सेटिंग लागू करने की अनुमति देता है।

इसके लिए केवल सीमा आपका हार्डवेयर है लेकिन एक सभ्य सर्वर और सही कर्नेल एक्सटेंशन के साथ यह आसान है। मैंने सफलतापूर्वक इस प्रकार के सेटअप को एक लाइनोड पर चलाया है, मेजबान और अतिथि दोनों को बहुत विरल दिया है। यदि आपका कमांड लाइन के साथ सहज है जो मुझे लगता है कि आप हैं तो आपको कोई समस्या नहीं होनी चाहिए।

इस प्रकार का सेटअप आपके द्वारा मॉनिटर किए जाने वाले आक्रमण वैक्टरों की संख्या को कम कर देता है और आपको होस्ट मशीनों की सुरक्षा पर ध्यान केंद्रित करने और साइट के आधार पर किसी अन्य चीज़ से निपटने की अनुमति देता है।

Comments

मैं मानता हूं कि वे बेहतर सुरक्षा प्रदान करते हैं और अन्य लाभ होते हैं, लेकिन उनमें कमियां भी हैं, जिनमें से कुछ का आपने उल्लेख किया है। इस प्रश्न का आधार हालांकि एक साझा अपाचे है। CageFS के साथ, एक रूट शोषण की बाधाओं को कम किया जाना चाहिए - एक वीएम के रूप में प्रभावी रूप से नहीं, लेकिन एक स्तर पर मैं उन साइटों के बारे में अच्छा महसूस करता हूं जिन्हें हम चला रहे हैं। मेरा मुख्य लक्ष्य उचित सुरक्षा में किसी भी तरह की गड़बड़ी से बचना है, जैसे कि किसी को रूट एक्सेस हासिल करने के लिए यह एक आदर्श तूफान होना चाहिए। उदाहरण के लिए, मैंने आसानी से अतीत में सहानुभूति के हमलों के बारे में नहीं देखा है और यह एक गंभीर गलती हो सकती है। Thx

— sa289

Answer 3

मेरा सुझाव है कि प्रत्येक साइट अपने अपाचे डेमॉन के तहत चलेगी, और अपाचे को चेरोटिंग करेगी। सभी सिस्टम php फ़ंक्शन विफल हो जाएगा क्योंकि Apache chroot वातावरण में / bin / sh तक पहुंच नहीं होगी। इसका मतलब यह भी है कि php का मेल () फ़ंक्शन भी काम नहीं करेगा, लेकिन यदि आप अपने ईमेल एप्लिकेशन से मेल भेजने के लिए बाहरी मेल प्रदाता का उपयोग कर रहे हैं, तो यह आपके लिए समस्या नहीं होनी चाहिए।

Comments

मैं इसे इस तरह से करना चाहूंगा - हमने इसे अतीत में (शून्य से घटते हुए) इस तरह से किया है, लेकिन दुर्भाग्य से यह हमें एक मानक नियंत्रण कक्ष सेटअप का उपयोग करने से रोकता है और यह अधिक समर्पित आईपी पते भी लेता है जब तक कि अधिक नहीं कर रहा हो अपाचे साइट पर प्रलेखित आंतरिक आईपी पते की तरह अपाचे को सुनकर अपाचे रिवर्स प्रॉक्सी सेटअप।

— sa289

आह हाँ, यह एक अच्छा बिंदु है जिसका आपने उल्लेख किया है। यह निश्चित रूप से आईपी से अधिक समर्पित आईपी की आवश्यकता होगी या एक रिवर्स प्रॉक्सी में वापस आ जाएगी।

— अल्फा 01

अगर किसी को भी यह उत्तर पढ़ने में उल्टा प्रॉक्सी सेटअप के लिए दस्तावेज में रुचि है, तो wiki.apache.org/httpd/DifferentUserIDsUsingReverseProxy

— sa289

Answer 4

SELinux के साथ मददगार हो सकता है mod_selinux। एक त्वरित हॉटो यहाँ चित्रित किया गया है:

मैं PHP स्क्रिप्ट को परिभाषित करने के लिए SELinux का उपयोग कैसे कर सकता हूं?

जैसा कि निर्देश थोड़ा दिनांकित है, मैंने जाँच की कि क्या यह आरएचईएल 7.1 पर काम करता है:

मैंने फेडोरा 19 के संस्करण का उपयोग किया है और आरएचईएल 7.1 + ईपीईएल के खिलाफ नकली के साथ संकलित किया है।

YMMV यदि आप बुनियादी एपल कॉन्फिग मॉक शिप्स का उपयोग करते हैं:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

selinux-policyवर्तमान को सुनिश्चित करने के लिए पहले अपना लक्ष्य सिस्टम अपग्रेड करें ।

लक्ष्य बॉक्स पर स्थापित करें (या पहले अपने स्थानीय दर्पण पर डालें):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

अब, आपको प्रत्येक वर्चुअल होस्ट को अपाचे श्रेणी में असाइन करना होगा। यह एक पंक्ति को जोड़कर किया जाता है जैसे कि नीचे दिए गए उदाहरण में selinuxDomainVal।

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

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

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

यदि आप लेबलिंग को सम्मानित करना चाहते हैं यदि आप एक सिस्टम रिलेबेल करते हैं, तो आप स्थानीय नीति को भी बेहतर अपडेट करेंगे!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Comments

मुझे इसका विचार पसंद है, लेकिन मुझे सर्वर पर सेलेनक्स चालू करना होगा जो अन्य कठिनाइयों का सामना कर सकता है। +1 हालांकि मुझे लगता है कि यह उन लोगों के लिए एक महान समाधान हो सकता है जो इसे बुरा नहीं मानते।

— sa289

Answer 5

बहुत सारे अच्छे तकनीकी उत्तर पहले से ही उपलब्ध हैं (कृपया यहां भी देखें : https://security.stackexchange.com/q/77/52572 और एक LAMP सर्वर की सुरक्षा के लिए सुझाव ), लेकिन मैं अभी भी यहां उल्लेख करना चाहूंगा सुरक्षा के बारे में एक महत्वपूर्ण बिंदु (अभी तक दूसरे दृष्टिकोण से): सुरक्षा एक प्रक्रिया है । मुझे यकीन है कि आपने पहले ही इस पर विचार कर लिया है, लेकिन मुझे उम्मीद है कि यह कभी-कभी पुनर्विचार करने के लिए भी उपयोगी हो सकता है (अन्य पाठकों के लिए भी)।

उदाहरण के लिए, आप प्रश्न में मुख्य रूप से तकनीकी उपायों पर ध्यान केंद्रित करते हैं: "यह प्रश्न केवल एक साझा अपाचे सेटअप की सुरक्षा के बारे में लक्षित है। विशेष रूप से, क्या कोई सुरक्षा कदम हैं जो लेने के लिए महत्वपूर्ण हैं लेकिन साझा किए जाने पर ऊपर दी गई सूची से गायब हैं। अपाचे और PHP। "

यहाँ लगभग सभी उत्तर और अन्य 2 प्रश्नों पर मैंने भी विशुद्ध रूप से तकनीकी प्रतीत होता है (अद्यतन रहने के लिए अनुशंसा को छोड़कर)। और मेरे दृष्टिकोण से यह कुछ पाठकों को एक भ्रामक धारणा बना सकता है, कि यदि आप एक बार सर्वोत्तम अभ्यास के अनुसार अपने सर्वर को कॉन्फ़िगर करते हैं, तो आप हमेशा के लिए सुरक्षित रहते हैं। तो कृपया उन बिंदुओं के बारे में मत भूलें जो मुझे उत्तर में याद हैं:

1. सबसे पहले, यह मत भूलो, कि सुरक्षा एक प्रक्रिया है और, विशेष रूप से, "प्लान-डू-चेक-एक्ट" चक्र के बारे में, जैसा कि आईएसओ 27001 ( http://www.isaca.org/) सहित कई मानकों द्वारा अनुशंसित है । जर्नल / अभिलेखागार / 2011 / खंड -4 / पृष्ठ / योजना-के लिए और कार्यान्वयन-ISO27001.aspx )। मूल रूप से, इसका मतलब है कि आपको अपने सुरक्षा उपायों को नियमित रूप से संशोधित करने, उन्हें अपडेट करने और परीक्षण करने की आवश्यकता है ।

2. नियमित रूप से आपको सिस्टम अपडेट करें। यह शून्य-दिवस की कमजोरियों का उपयोग करके लक्षित हमलों के खिलाफ मदद नहीं करेगा, लेकिन यह लगभग सभी स्वचालित हमलों के खिलाफ मदद करेगा।

3. अपने सिस्टम की निगरानी करें। मुझे जवाबों में यह बात याद आ रही है। मेरे दृष्टिकोण से, आपके सिस्टम के साथ कुछ समस्या के बारे में जल्द से जल्द सूचित किया जाना बेहद महत्वपूर्ण है।

   इसके बारे में आंकड़े क्या कहते हैं: "घुसपैठ से खोज का औसत समय 173.5 दिन है" ( http://www.triumfant.com/detection.html ), "पता लगाने से पहले 205 दिनों की संख्या" ( https: // www2) .fireeye.com / rs / fireye / images / rpt-m-Trends-2015 . -pdf )। और मुझे आशा है कि ये संख्याएं वह नहीं हैं जो हम सभी चाहते हैं।

   न केवल सेवा की स्थिति (जैसे नागियोस) की निगरानी के लिए बहुत सारे समाधान (नि: शुल्क सहित) हैं, बल्कि घुसपैठ का पता लगाने वाले सिस्टम (ओएसएसईसी, स्नॉर्ट) और सिएम सिस्टम (ओएसएसआईएम, स्पंक) भी हैं। यदि यह बहुत जटिल हो जाता है, तो आप कम से कम '' असफल 2बान '' और 'या' को आगे बढ़ाने में सक्षम हो सकते हैं जैसे कि आप अलग-अलग syslog सर्वर में लॉग इन करते हैं, और महत्वपूर्ण घटनाओं के बारे में ई-मेल सूचनाएँ देते हैं।

   फिर, यहां सबसे महत्वपूर्ण बिंदु यह नहीं है कि आप किस निगरानी प्रणाली को चुनते हैं, सबसे महत्वपूर्ण यह है कि आपके पास कुछ निगरानी है और इसे अपने "प्लान-डू-चेक-एक्ट" चक्र के अनुसार नियमित रूप से संशोधित करें ।

4. कमजोरियों के प्रति जागरूक रहें। निगरानी के समान। बस कुछ भेद्यता सूची को अधिसूचित करने के लिए सदस्यता लें, जब अपाचे या आपके सेटअप के लिए महत्वपूर्ण अन्य सेवा के लिए कुछ महत्वपूर्ण भेद्यता की खोज की जाती है। लक्ष्य को आपके अगले नियोजित अद्यतन से पहले दिखाई देने वाली सबसे महत्वपूर्ण चीजों के बारे में सूचित किया जाना है।

5. किसी घटना के मामले में एक योजना बनाएं (और नियमित रूप से अपडेट करें और इसे अपने "प्लान-डू-चेक-एक्ट-चक्र" के अनुसार संशोधित करें)। यदि आप सुरक्षित कॉन्फ़िगरेशन के बारे में प्रश्न पूछते हैं, तो इसका मतलब है कि आपके सिस्टम की सुरक्षा आपके लिए महत्वपूर्ण हो जाती है। हालाँकि, अगर आपको सभी सुरक्षा उपायों के बावजूद सिस्टम हैक हो गया है तो आपको क्या करना चाहिए? फिर से, मुझे यहां केवल तकनीकी उपायों से मतलब नहीं है जैसे "ओएस को पुनर्स्थापित करें": आपको लागू कानून के अनुसार दुर्घटना की रिपोर्ट कहां करनी चाहिए? क्या आपको अपने सर्वर को तुरंत बंद / डिस्कनेक्ट करने की अनुमति है (आपकी कंपनी के लिए कितना खर्च होता है)? यदि मुख्य जिम्मेदार व्यक्ति छुट्टी / बीमार है तो किससे संपर्क किया जाना चाहिए?

6. एक बैकअप, संग्रह और / या प्रतिस्थापन / प्रतिकृति सर्वर है। सुरक्षा का अर्थ आपकी सेवा की उपलब्धता भी है। नियमित रूप से अपने बैकअप / संग्रह / प्रतिकृति की जाँच करें और नियमित रूप से प्रक्रियाओं को पुनर्स्थापित करें।

7. भेदन परीक्षण? (फिर से, "प्लान-डू-चेक-एक्ट" चक्र देखें): यदि यह बहुत अधिक लगता है, तो आप कम से कम कुछ मुफ्त ऑनलाइन टूल आज़मा सकते हैं, जो मैलवेयर और सुरक्षा समस्याओं के लिए आपकी वेब सेवाओं को स्कैन करते हैं।

Comments

लोगों को ध्यान में रखने के लिए अच्छा जोड़। यदि यह किसी के लिए भी उपयोगी है, तो मैंने आपके द्वारा पोस्ट किए गए पहले दो लिंक के माध्यम से बहुत समय व्यतीत करने में बिताया है और यदि मुझे कुछ भी याद नहीं है तो मुझे यह देखने के लिए कि उन्हें क्या मिला है। उन लोगों से जुड़े संसाधन जिन्हें मैंने सोचा था कि सबसे उपयोगी थे बेंचमार्क s.cisecurity.org/downloads/show-single/… और iase.disa.mil/stigs/app-security/web-servers/Pages/index.aspx , हालांकि दोनों के बीच ओवरलैप की एक अच्छी मात्रा थी। अगर सुरक्षा सर्वोपरि है तो मैं कुछ भी प्रमुख नहीं पढ़ सकता लेकिन फिर भी पढ़ने लायक हूं।

— 2228 पर sa289

Answer 6

आपका उपयोग मामला डॉकटर कंटेनरों के लिए आदर्श है।

प्रत्येक कंटेनर एक ग्राहक या ग्राहक का प्रतिनिधित्व कर सकता है, अद्वितीय उपयोगकर्ता आईडी के साथ प्रत्येक अपाचे कंटेनर समूह को अतिरिक्त सुरक्षा के रूप में सौंपा गया है। कुंजी आपके कंटेनर स्टैक को शुरू करने से पहले कंटेनर स्टार्ट पर रूट विशेषाधिकार छोड़ने के लिए होगी। प्रत्येक ग्राहक अपने स्वयं के अनूठे पासवर्ड के साथ अपनी स्वयं की डीबी सेवा प्राप्त करता है, दर्जनों आभासी मशीनों के खड़े होने के बिना, प्रत्येक को अपने स्वयं के विशेष-स्नोफ्लेक कर्नेल और अन्य ओवरहेड की आवश्यकता होती है। आखिरकार, docker के दिल में chroot है। उचित रूप से प्रशासित, मैं किसी भी दिन एक विशिष्ट आभासी क्लस्टर पर ले जाऊँगा।

Comments

इसका मतलब यह होगा कि प्रभावी रूप से प्रति ग्राहक एक अपाचे डेमॉन होगा? यदि ऐसा है, तो मुझे लगता है कि यह खामी अल्फा01 के जवाब के समान होगी।

— sa289

हां, यह अल्फा 01 के समान है, हालांकि अनुप्रयोगों को डॉक्यूमेंट करने से मेजबान कॉन्फ़िगरेशन सिरदर्द में बहुत अधिक होता है। उस ने कहा, आपके नियंत्रण कक्ष का मुद्दा कायम है कि क्या आप चेरोट / कंटेनर दृष्टिकोण या एक-वीएम-प्रति-ग्राहक दृष्टिकोण का उपयोग करते हैं।

— Stephan

धन्यवाद। हालांकि एक नियंत्रण कक्ष के बिना, मैं अभी भी बल्कि एक रिवर्स प्रॉक्सी करने से बचता हूं या फिर अधिक सार्वजनिक आईपी की आवश्यकता होती है जब तक कि मुझे गलतफहमी न हो कि यह सेटअप कैसे काम करेगा।

— sa289

अधिकांश दुकानें जिन्हें मैंने देखा है (बड़े और छोटे) रिवर्स प्रॉक्सी दृष्टिकोण लेते हैं। मैं व्यक्तिगत रूप से HAProxy का उपयोग करता हूं, यह आदर्श रूप से उस बड़े पैमाने पर अलगाव के अनुकूल है जिसे आप खोज रहे हैं। यह अत्यधिक प्रदर्शन करने वाला है, और आपको क्षैतिज रूप से बहुत कुशलता से स्केल करने की अनुमति देता है, और उस तरह की विदेशी जटिलता की आवश्यकता नहीं है जो एमएसचुएट के समाधान में स्पष्ट प्रतीत होती है।

— Stephan

Answer 7

यहाँ पहले से ही बहुत अच्छे सुझाव हैं। वहाँ सामान है कि चर्चा में अब तक याद किया गया है।

वेब पृष्ठों की सेवा के भाग के रूप में उन प्रक्रियाओं के बाहर ध्यान दें। यानी यह सुनिश्चित करें कि आपके सभी क्रॉन जॉब्स जो अविश्वसनीय डेटा को छूते हैं, उपयुक्त उपयोगकर्ता के रूप में और उपयुक्त जेल में चल रहे हैं, चाहे वे नौकरियां उपयोगकर्ता द्वारा परिभाषित की गई हों या नहीं।

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

PHP ऐप आमतौर पर अपनी स्वयं की स्थिर फ़ाइलों की सेवा नहीं करते हैं, और यदि आपके पास एक साझा अपाचे प्रक्रिया है, तो मैं अनुमान लगा रहा हूं कि आपकी अपाचे प्रक्रिया मेजबान वातावरण से सीधे जेल से बाहर सामान पढ़ रही है? यदि ऐसा है, तो यह विभिन्न प्रकार की चिंताओं को खोलता है।

.htaccessफाइलें एक स्पष्ट है, जहां आपको बहुत सावधानी बरतने की आवश्यकता है कि आप क्या अनुमति देते हैं। बहुत से नहीं तो अधिकांश पर्याप्त php ऐप्स बहुत .htaccess फ़ाइल व्यवस्थाओं पर निर्भर होते हैं, जिन्हें आप अपनी नियोजित योजना को नष्ट किए बिना शायद अनुमति नहीं दे सकते।

कम स्पष्ट है कि कैसे अपाचे तय करता है कि वैसे भी एक स्थिर फ़ाइल क्या है। उदा। यह एक *.php.gifया *.php.enफ़ाइल के साथ क्या करता है ? यदि यह तंत्र या कोई अन्य भेदभाव करता है, जो एक स्थिर फाइल है, तो क्या एपेक के लिए जेल के बाहर से php चलाना संभव है? मैंने स्थैतिक सामग्री के लिए एक अलग लाइट वेट वेब सर्वर स्थापित किया है, जो डायनामिक कंटेंट को निष्पादित करने के लिए किसी भी मॉड्यूल के साथ कॉन्फ़िगर नहीं किया गया है, और एक लोड बैलेंसर है जो यह तय करता है कि कौन से स्टैटिक सर्वर को भेजना है और कौन से डायनामिक को।

स्टीफन के डॉकर सुझाव के बारे में, एक एकल वेब सर्वर होना संभव है जो कंटेनर के बाहर बैठता है, और जो गतिशील सामग्री के लिए प्रत्येक कंटेनर में php डेमॉन से बात करता है, जबकि दूसरा वेब सर्वर भी होता है, जो एक डॉकटर कंटेनर में बैठता है, और जो अपनी सामग्री के लिए प्रत्येक उपयोग के संस्करणों को साझा करता है, और इस प्रकार स्थिर सामग्री की सेवा करने में सक्षम होता है, जो पिछले पैराग्राफ के समान ही है। मैं विभिन्न जेल प्रकार के दृष्टिकोणों के बीच डॉकटर की सराहना करता हूं, लेकिन इस या अन्य जेल प्रकार के तरीकों से, आपके पास काम करने के लिए अन्य मुद्दों का एक गुच्छा होगा। फ़ाइल अपलोड कैसे काम करता है? क्या आप प्रत्येक कंटेनर में फ़ाइल स्थानांतरण डेमोंस रखते हैं? क्या आप एक PAAS शैली के आधार पर दृष्टिकोण अपनाते हैं? आप कंटेनर के अंदर उत्पन्न लॉग को कैसे सुलभ बनाते हैं, और उन्हें रोल? आप क्रोन नौकरियों का प्रबंधन और संचालन कैसे करते हैं? क्या आप उपयोगकर्ताओं को किसी भी प्रकार का शेल एक्सेस देने जा रहे हैं, और यदि ऐसा है, तो क्या कंटेनर के भीतर एक और डेमॉन है? आदि आदि।

Comments

धन्यवाद। अपने प्रश्न का उत्तर देने के लिए - PHP के लिए जेल के बाहर भागना संभव नहीं है, भले ही CageFS के कारण एक अलग फ़ाइल एक्सटेंशन का उपयोग किया जाए, जहां तक ​​मैं बता सकता हूं। मैंने दोनों की कोशिश की SetHandlerऔर AddTypeएक नए विस्तार को PHP के रूप में संसाधित किया गया और इसे जेल में डाल दिया गया। मुझे नहीं पता कि इसके आस-पास कोई रास्ता है, लेकिन यही है कि मैं उम्मीद कर रहा हूं कि अगर मैं कुछ याद करता हूं तो कोई इसे इंगित करेगा। हां, अपाचे जेलों से सीधे पढ़ रहा है। क्रॉन जॉब्स को देखने का अच्छा बिंदु - यह विभिन्न चीजों की तरह लगता है जो रूट के रूप में चलते हैं जो रिपोर्ट की गई कमजोरियों के बहुत सारे स्रोत हैं।

— sa289

पुन:, .htaccessमैं इन अनुमति देने के लिए AllowOverrideList का उपयोग किया था इस विश्वास में Add{Charset,DefaultCharset,Encoding,Handler,OutputFilter,OutputFilterByType,Type} Allow Auth{GroupFile,Name,Type,UserFile} Deny DirectoryIndex ErrorDocument Expires{Active,ByType,Default} FileETag ForceType Header IndexIgnore Order php_flag php_value Redirect RedirectMatch Remove{Handler,Type} RequestHeader Require Rewrite{.various.} Satisfy Set{Env,EnvIf,EnvIfNoCase,Handler} SSLRequireSSL:। मेरी चिंता AddType, AddHandler और SetHandler है, लेकिन Drupal फ़ाइल अपलोड डायर में गहराई से रक्षा के लिए SetHandler का उपयोग करता है।

— 1828 पर sa289

यदि आप लोगों को हैंडलर के साथ छेड़छाड़ करने की अनुमति दे रहे हैं, तो आपको सभी परिभाषित कार्यों से गुजरने और यह सुनिश्चित करने की आवश्यकता है कि वे सुरक्षित हैं, एफपी नहीं।

— mc0e

अच्छी बात! मैंने पुष्टि की SetHandler server-infoया SetHandler server-statusएक htaccess फ़ाइल में एक ऐसा तरीका है जिससे कोई भी हमले को आसान बना सकता है या जानकारी का खुलासा कर सकता है कि आदर्श रूप से सर्वर पर सभी VirtualHosts (उदाहरण के लिए भाला फ़िशिंग के लिए इस्तेमाल किया जा सकता है) या अन्य साइटों पर वर्तमान ट्रैफ़िक का खुलासा नहीं किया जाएगा। । मुझे बस उन हैंडलर / टाइप में से कुछ को हटाने का सहारा लेना पड़ सकता है AllowOverrideList। क्या आप किसी भी तरह से सूची को सभी संभावित कार्यों / संचालकों को जानते हैं? मैंने ऑनलाइन खोज करने की कोशिश की लेकिन अच्छा जवाब नहीं मिला।

— sa289

आपको इनाम दिया गया क्योंकि हमारी चर्चा सूचना प्रकटीकरण भेद्यता की ओर ले जाती है जिसे मैंने कवर नहीं किया था। कृपया मुझे बताएं कि क्या आपके पास कार्रवाई / संचालकों को सूचीबद्ध करने के बारे में प्रतिक्रिया है। Thx

— sa289

Answer 8

पहली बात जो मैं नहीं देख रहा हूँ वह है प्रक्रिया प्रबंधन इसलिए एक प्रक्रिया सीपीयू या रैम (या I / O की उस प्रक्रिया के लिए अन्य प्रक्रिया को भूखा नहीं रख सकती है, हालाँकि आपका फाइलसिस्टम को रोकने के लिए आर्किटेक्चर किया जा सकता है)। अपने PHP उदाहरणों के लिए "कंटेनरों" के दृष्टिकोण का एक प्रमुख लाभ बनाम उन सभी को एक "ओएस" छवि पर चलाने की कोशिश करना है, जिससे आप संसाधन उपयोग को बेहतर तरीके से प्रतिबंधित कर सकते हैं। मुझे पता है कि यह आपका डिज़ाइन नहीं है, लेकिन इस पर विचार करने के लिए कुछ है।

वैसे भी, अपाचे के पीछे PHP के चलने के उपयोग के मामले में मूल रूप से प्रॉक्सी के रूप में कार्य करना। suexec एपाचे उपयोगकर्ता के रूप में चलने से कुछ नहीं रोकता है - यह दूसरे उपयोगकर्ता के रूप में चलाने की क्षमता प्रदान करता है । तो एक चिंता यह सुनिश्चित करने वाली है कि यह सब ठीक से किया जा रहा है - इसके लिए डॉक्टर पृष्ठ उस संभावित खतरे को बताता है: https://httpd.apache.org/docs/2.2/suexec.html । तो, आप जानते हैं, नमक का अनाज और वह सब।

एक सुरक्षा के दृष्टिकोण से यह, के साथ काम करने के लिए उपयोगकर्ता बाइनरी की एक सीमित सेट (जो आपूर्ति cagefs) के लिए विशेष रूप से उन्हें अलग तरह से या एक अलग पुस्तकालय के खिलाफ संकलित किए जाते हैं सहायक हो सकता है (उदाहरण के लिए एक है कि क्षमताओं है कि अवांछित हैं शामिल नहीं है) लेकिन खतरा यह है कि उस बिंदु पर अब आप अपडेट के लिए एक ज्ञात वितरण का पालन नहीं कर रहे हैं, आप अपने PHP इंस्टॉलेशन (कम से कम उपयोगकर्ता अंतरिक्ष उपकरण के संबंध में) के लिए एक अलग वितरण (केजफ़्स) का पालन कर रहे हैं। यद्यपि आप संभवतः पहले से ही क्लाउडलाइन के साथ एक विशिष्ट वितरण का अनुसरण कर रहे हैं जो कि एक वृद्धिशील जोखिम है, जरूरी नहीं कि यह अपने आप में दिलचस्प हो।

मैं AllowOverride को उस स्थान पर छोड़ दूंगा जहाँ आपने इसका इरादा किया होगा। गहराई में रक्षा के पीछे मुख्य विचार यह है कि आपके पूरे स्टैक की सुरक्षा के लिए किसी एक परत पर भरोसा न किया जाए। हमेशा मान लें कि कुछ गलत हो सकता है। ऐसा होने पर शमन करें। तब तक दोहराएं, जब तक कि आप अपनी साइट के सामने केवल एक बाड़ न होने के बावजूद भी आपके साथ कम नहीं हो जाते।

लॉग प्रबंधन महत्वपूर्ण होने जा रहा है। अलग-अलग फ़ाइल सिस्टम में चलने वाली कई सेवाओं के साथ, जब कोई समस्या है तो सहसंबंधित करने के लिए गतिविधियों को एकीकृत करना एक मामूली दर्द हो सकता है यदि आपने शुरुआत से सेट नहीं किया है।

यही मेरा दिमाग डंप है। आशा है कि वहाँ कुछ बेहद उपयोगी है। :)

Comments

धन्यवाद। CloudLinux में आपके द्वारा बताई गई संसाधन समस्या को हल करने में मदद करने के लिए कुछ लाइटवेट वर्चुअल एनवायरनमेंट (LVE) और MySQL के गवर्नर हैं।

— sa289

वो बहुत कूल है।

— मैरी