💅🏼 🤚🏼 ☦️ सुरक्षित वेब संसाधन की ओर। भाग 1

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

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

सर्वर सॉफ्टवेयर कॉन्फ़िगरेशन

नगनेक्स + php-fpm

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

आइए साइट के विन्यास से ही शुरू करें:

location /index.php { ... fastcgi_pass unix:/var/run/php-fpm/php-fpm.socket; ... }

वेब एप्लिकेशन को डिज़ाइन करने की सलाह दी जाती है ताकि यह htdocs में सिर्फ एक php फाइल से काम कर सके और इसी तरह लोकेशन - /index.php को कॉन्फ़िगर कर सके। यह htdocs में बाढ़ php शेल को निष्पादित करने की संभावना को समाप्त करता है। हम इस लेख के दूसरे भाग में इस पर लौटेंगे।

यहाँ वर्णित fix_pathinfo के साथ फिक्स बग। हम php.ini को संपादित करते हैं और fix_pathinfo पैरामीटर के मान को बदलते हैं

 cgi.fix_pathinfo=0

हम स्क्रिप्ट किडी के जीवन को जटिल बनाते हैं और यूए ( लेख से ) के लिए लोकप्रिय स्कैनर को ब्लॉक करते हैं :

 if ( $http_user_agent ~* (nmap|nikto|wikto|sf|sqlmap|bsqlbf|w3af|acunetix|havij|appscan) ) { return 403; }

मेरा विश्वास करो, "हैकर्स" के शेर का हिस्सा बाहर गिर जाएगा :)

CSRF बैसाखी

निम्न नियम मैं अत्यधिक उपयोग के लिए अनुशंसा नहीं करता , लेकिन यदि आप एक समस्या का सामना कर रहे हैं जो कोई आपके उपयोगकर्ताओं पर CSRF का सक्रिय रूप से उपयोग कर रहा है, तो निम्नलिखित नियम मदद कर सकता है यदि CSRF के खिलाफ सुरक्षा जोड़ने का कोई सामान्य तरीका नहीं है

 # ANTI CSRF HACK valid_referers blocked example.com www.example.com; if ($invalid_referer) { set $possible_csrf 1; } if ($request_method = POST) { set $possible_csrf "${possible_csrf}2"; } if ($possible_csrf = 12) { return 403; }

इस तरह के डरावने निर्माणों की आवश्यकता है, क्योंकि nginx if में कई स्थितियों का समर्थन नहीं करता है, और nested ifs का समर्थन भी नहीं करता है। पहली पंक्ति में हम रेफरी को सूचित करते हैं जो मान्य होगा (हमारी साइट से फ़ायरवॉल और रेफरी द्वारा अवरुद्ध - कट)। और यदि विधि = POST, तो हम उपयोगकर्ता को रोकते हैं। आजकल, लगभग कोई भी प्रॉक्सी का उपयोग नहीं करता है जो क्लाइंट अनुरोधों में संदर्भित कटौती करता है, लेकिन ऐसी संभावना है। इसलिए, उपरोक्त उदाहरण एक समाधान नहीं है, बल्कि केवल एक गंदा हैक है।

एंटी-डीएनएस पिनिंग

होस्ट पार्सिंग नियमों को कॉन्फ़िगर किया जाना चाहिए ताकि यदि HTTP हेडर में HOST मान हमारे संसाधन नहीं है, तो 404 लौटाएं। उदाहरण के लिए ।

एक्स फ़्रेम-विकल्पों को

हम महत्वपूर्ण शीर्ष जोड़ते हैं (हम व्लादिमीरकोचेत्कोव के लेख से जानकारी भी प्राप्त करेंगे)। सबसे पहले, हम iframe में अपने संसाधन के प्रदर्शन को अक्षम करेंगे:

 add_header X-Frame-Options DENY;

यह हमारे संसाधन को iframe के माध्यम से संभावित DDOS से बचाएगा, साथ ही साइट पर संभावित क्लिकजैकिंग से भी। Iframes का उपयोग करके सीएसएस ट्रिक्स के बारे में मत भूलना।

एक्स-सामग्री-प्रकार-विकल्प

 add_header X-Content-Type-Options nosniff;

यह IE को बताएगा कि सामग्री-प्रकार को स्वचालित रूप से निर्धारित करने की आवश्यकता नहीं है, लेकिन आपको पहले से दिए गए सामग्री-प्रकार का उपयोग करना होगा। IE में पहले से ही सामग्री प्रकार के स्वचालित निर्धारण से संबंधित सुरक्षा कीड़े थे।

एक्स-XSS-संरक्षण

 add_header X-XSS-Protection "1; mode=block;";

IE के लिए एक शीर्षक भी। अंतर्निहित XSS सुरक्षा को सक्रिय करता है।

एक्स-सामग्री-सुरक्षा-नीति

सुंदर विशिष्ट शीर्षक, इसके साथ सावधान रहें

 add_header X-Content-Security-Policy "allow 'self';"; add_header X-WebKit-CSP "allow 'self';";

यह निर्धारित करता है कि JS को किस डोमेन से लोड किया जा सकता है (IE10 के लिए X-Content-Security-Policy, FF / Chrome के लिए X-WebKit-CSP)। ऊपर दिए गए उदाहरण में, एक नियम निर्दिष्ट किया गया है जो केवल उसी डोमेन से JS लोड करने की अनुमति देता है।

सख्त-परिवहन-सुरक्षा

यदि आपका संसाधन https के माध्यम से काम करता है और 80 वें पोर्ट से 443 (सुविधा के लिए) पर रीडायरेक्ट होता है, तो क्लाइंट कुछ समय के लिए असुरक्षित कनेक्शन बनाए रख सकता है। यह शीर्ष लेख इस बहुत कम समय ( TOR में यातायात अवरोधन ) में MITM की संभावना को बाहर करता है। अधिक जानकारी यहाँ ।

फ़ायरवॉल

सबसे महत्वपूर्ण विन्यास में से एक। सामान्य विचार यह है: हम कई अनुमति देते हैं, बाकी सब पर रोक लगाते हैं। मैं एक iptables गुरु नहीं हूं, शायद टिप्पणियों में कोई मुझे सही करेगा और हम बेहतर समाधान के लिए आएंगे। हम मानते हैं कि eth0 में एक बाहरी इंटरफ़ेस है और हम इसे इसे सीमित कर देंगे (आमतौर पर आंतरिक नेटवर्क से पूर्ण पहुंच)।

 -A INPUT -i eth0 -p icmp -j ACCEPT #      -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT #        -A INPUT -s 12.34.56.78 -i eth0 -j ACCEPT #   IP ,            (  ) -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT # ssh -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT # web -A INPUT -i eth0 -j DROP #

आप DDoS के दौरान इस कॉन्फ़िगरेशन में ऑटो-बैन भी जोड़ सकते हैं, लेकिन मैं पहली आवश्यकता होने तक उनका उपयोग नहीं करना पसंद करता हूं। शायद मैं आईपी के साथ एक साथ कनेक्शन की एक सीमा जोड़ूंगा। प्रत्येक संसाधन के साथ सब कुछ काफी विशिष्ट है।

सर्वर की निगरानी करें

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

फ़ाइल सिस्टम की निगरानी करें

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

 apt-get install iwatch

~~और हमें एक उत्कृष्ट घड़ी मिलती है।~~ config फाइल आदि / iwatch / iwatch.xml पर स्थित है और इस तरह दिखाई देती है:

 <?xml version="1.0" ?> <!DOCTYPE config SYSTEM "/etc/iwatch/iwatch.dtd" > <config lang="xml"> <guard email="youremail@gmail.com" name="IWatch"/> <watchlist> <title>Operating System</title> <contactpoint email="root@localhost" name="Administrator"/> <path type="single" syslog="on">/bin</path> <path type="single" syslog="on">/sbin</path> <path type="single">/etc</path> <path type="recursive">/lib</path> <path type="exception">/lib/modules</path> </watchlist> </config>

सब कुछ बहुत स्पष्ट है। हम उन फ़ोल्डरों को सूचीबद्ध करते हैं जिनकी हमें आवश्यकता है, हमें क्या चाहिए - हम उस मेल को बाहर करते हैं और निर्दिष्ट करते हैं जहां रिपोर्ट भेजने के लिए (सब कुछ जीमेल पर ठीक आता है)।

यदि आप स्रोत से स्क्रिप्ट को बस डाउनलोड करने का निर्णय लेते हैं, तो पर्ल में आवश्यक निर्भरताएं बहुत सरलता से वितरित की जाती हैं - cpan #modulename, उदाहरण के लिए cpan XML :: SimpleObject :: LibXML।

AppArmor, SELinux, chroot और अन्य Pribluda

दुर्भाग्य से, यदि आप Google में "SELinux" दर्ज करते हैं, तो पहला संकेत "SELinux अक्षम" होगा। AppArmor में एक समान गीत है। यह आंशिक रूप से इस तथ्य के कारण है कि ये सुरक्षा विशेषताएं डिफ़ॉल्ट रूप से सक्षम हैं और काम करने वाले सॉफ़्टवेयर के लिए समस्याएं पैदा करती हैं। और आपने पहले से ही एक घंटे का समय बिताया और एक तिहाई कप कॉफी पी ली, और सोचा कि क्यों जरूरी स्क्रिप्ट / सॉफ्टवेयर काम नहीं करता है। मैं अभी भी इन "लिनक्स दुनिया के जादू" से निपटने और निम्नलिखित लेख पढ़ने का सुझाव दूंगा:

मैं यह कहना चाहता हूं कि वास्तव में ऐसे तंत्र से पेंटेस्ट / हैकिंग की समस्याएं हैं , इसलिए उन्हें नजरअंदाज न करें।

IPS, IDS, WAF

यदि आपके पास पहले से ही एक मौजूदा व्यावसायिक परियोजना है, तो मेरा सुझाव है कि आप WAF / IPS / IDS की स्थापना पर किसी भी लेख को पढ़ना छोड़ दें और तैयार किए गए समाधानों का उपयोग करें, उदाहरण के लिए, F5 से या Cloudflare से । Cloudflare में एक टन की समस्या है (हमलावरों के लिए)। अगर मैं देखता हूं कि संसाधन उस पर है, तो इसका मतलब तुरंत एक्स 5 खर्च करने का समय है। मैं कह सकता हूं कि बेनामी, 1337day.com (inj3ct0r) और अन्य समर्थक सुरक्षा बिल्कुल Cloudflare का उपयोग करते हैं (कोई विज्ञापन नहीं, यह सिर्फ एक तथ्य है)। बेशक, इन प्रणालियों को दरकिनार करने के लिए विकल्प हैं, लेकिन उन्हें आमतौर पर हमलावर से अतिरिक्त लागत की आवश्यकता होती है, उदाहरण के लिए, अलग-अलग आईपी पते के एक समूह के साथ क्लाउड में कारों को किराए पर लेने के लिए, लेकिन यह थोड़ा अलग विषय के लिए एक विषय है।

ठीक है, अगर परियोजना केवल अपने पथ की शुरुआत में है और ऐसी सेवाओं के लिए कोई पैसा नहीं है, तो मैं निम्नलिखित लेखों को प्रस्तावित करता हूं:

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

डीएनएस सुरक्षा

यदि आप अपने DNS सर्वर (या किसी और के) का उपयोग कर रहे हैं, तो अपने द्वारा उपयोग किए जा रहे डोमेन के लिए उसके (उसके) के लिए AXFR अनुरोधों की जांच करना न भूलें। यहाँ समस्या का विस्तार से वर्णन किया गया है।

Grsecurity

मुझे उम्मीद है कि किसी दिन मेरे हाथ ग्रासीसिटी तक पहुंच जाए । और फिर मैं विषय में उसके बारे में जानकारी जोड़ूंगा।

आचरण बैकअप, सच chmod / chown, निगरानी लॉग (error.log incl।) और सिस्टम ईवेंट, मैं चुप रहूंगा, यह दी जानी चाहिए।

श्रृंखला:
सुरक्षित वेब संसाधन की ओर। भाग 1 - सर्वर सॉफ्टवेयर
सुरक्षित वेब संसाधन की ओर। भाग 2 - विकास
सुरक्षित (वेब) संसाधन बनाने के रास्ते पर। भाग 3 - कार्यालय, कर्मचारी

सुरक्षित वेब संसाधन की ओर। भाग 1 - सर्वर सॉफ्टवेयर