लिनक्स पर एक वेब सर्वर सुरक्षित करना

नमस्कार, हेब्र!

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


लेखक ने हैकर्नून वेबसाइट पर 9 वें अध्याय का एक अंश प्रकाशित किया है, जिसका सुझाव हम आपको देते हैं।

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

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

सिस्टम समूह और न्यूनतम विशेषाधिकार का सिद्धांत

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

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

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

 $ nano datafile.txt $ chmod 770 datafile.txt 

यदि आपके सिस्टम में अभी तक आपके स्वयं के अलावा अन्य उपयोगकर्ता खाते नहीं हैं, तो adduser का उपयोग करके इस तरह का एक खाता बनाएं - यह डेबियन / उबंटू में किया जाता है - या उपयोगकर्तापैड का उपयोग करना, जैसा कि CentOS में प्रथागत है। useradd कमांड उबंटू पर भी काम करेगा।

उपयोगकर्ता कमांड, डेबियन adduser विपरीत adduser उपयोगकर्ता पासवर्ड को अलग से उत्पन्न करने की आवश्यकता होती है:

 # useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully 

su कमांड का उपयोग करके, हम नए उपयोगकर्ता पर स्विच करते हैं। उसके पासवर्ड दर्ज करने के बाद, इस उपयोगकर्ता की ओर से निम्नलिखित सभी कमांड निष्पादित किए जाएंगे। आप इस विशेष उपयोगकर्ता की ओर से काम करेंगे; न ज्यादा न कम। यदि आप डेटा फ़ाइल datafile.txt ( cat का उपयोग करके) को पढ़ने की कोशिश करते हैं, तो आपके लिए अब कुछ भी काम नहीं करेगा; जैसा कि आपको याद है, केवल समूह के सदस्यों ने ही अधिकार पढ़े हैं। जब किया जाता है, तो नए उपयोगकर्ता शेल से बाहर exit लिए बाहर निकलें और अपने मूल शेल पर वापस लौटें।

 $ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exit 

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

हम एक नया समूह बनाएंगे, जिसके साथ हम अपने एप्लिकेशन के डेटा को प्रबंधित कर सकते हैं, और फिर chown का उपयोग करके अपनी डेटा फ़ाइल के गुणों को संपादित कर सकते हैं। उबंटू तर्क: ऐप-डेटा-समूह उबंटू उपयोगकर्ता के पास फ़ाइल का स्वामित्व छोड़ देता है, लेकिन उसका समूह एक नए में बदल जाता है: ऐप-डेटा-समूह।

 # groupadd app-data-group # chown ubuntu:app-data-group datafile.txt 

इस फ़ाइल के "विस्तारित" आउटपुट को पाने के लिए ls चलाएं और इसकी नई अनुमतियां और स्थिति देखें। कृपया ध्यान दें: जैसा कि अपेक्षित था, फ़ाइल app-data-group से संबंधित ubuntu उपयोगकर्ता के स्वामित्व में है।

 $ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txt 

आप अपने उपयोगकर्ता को app-data-group जोड़ने के लिए usermod का उपयोग कर सकते हैं, और फिर शेल में स्विच करने के लिए su कमांड का उपयोग कर सकते हैं जिसमें किसी अन्य उपयोगकर्ता का खाता तैनात है। अब, भले ही फ़ाइल तक पहुंचने के अधिकार इसे सभी "अन्य" से अवरुद्ध करते हैं - और आप निश्चित रूप से इस समय "अलग" उपयोगकर्ता हैं - आपको इस फ़ाइल को स्वतंत्र रूप से पढ़ना चाहिए, क्योंकि आप आवश्यक समूह से संबंधित हैं।

 # usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello World 

su कमांड का उपयोग करके, हम उपयोगकर्ता खातों के बीच स्विच करते हैं। वे मेरी datafile.txt फाइल में दर्ज हैं। इस तरह का एक संगठन एक बहु-उपयोगकर्ता प्रणाली में उत्पन्न होने वाले एक्सेस अधिकारों के साथ विभिन्न प्रकार की जटिल समस्याओं को समाप्त करने का सही और प्रभावी तरीका है।

वास्तव में, इसका उपयोग न केवल व्यक्तिगत उपयोगकर्ताओं को आवश्यक एक्सेस अधिकार प्रदान करने के लिए किया जाता है - कई सिस्टम प्रक्रियाएं भी आवश्यक समूहों में सदस्यता निर्धारित नहीं किए जाने पर अपने कार्यों को पूरा करने में सक्षम नहीं होंगी। आप / etc / group फाइल को तिरछे देख सकते हैं - ध्यान दें कि आपके अपने समूहों के कितने सिस्टम प्रोसेस हैं ...

/ Etc / समूह फ़ाइल की सामग्री की संक्षिप्त सूची:

 $ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9: uucp:x:10: man:x:12: proxy:x:13: […] 

कंटेनर प्रक्रिया अलगाव

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

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

जिन "कंटेनरों" के बारे में मैं बात कर रहा हूँ, उन्हें LXC के साथ समझाने की ज़रूरत नहीं है। अन्य कंटेनर प्रौद्योगिकियां जैसे डॉकर आज अधिक लोकप्रिय हो रही हैं।

खतरनाक उपयोगकर्ता आईडी मानों के लिए जाँच करना

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

इस मामले में, यह अच्छा है कि ऐसे दोषियों की पहचान करना मुश्किल नहीं है: उनके उपयोगकर्ता और / या समूह आईडी, जैसे कि व्यवस्थापक, "0" होगा। / Etc / निर्देशिका में passwd फ़ाइल पर एक नज़र डालें। इस फ़ाइल में प्रत्येक नियमित और सिस्टम उपयोगकर्ता खाते के लिए एक रिकॉर्ड है जो पहले से ही सिस्टम में मौजूद है। पहले फ़ील्ड में खाता नाम (इस स्थिति में, रूट और ubuntu) शामिल है, और दूसरे फ़ील्ड में पासवर्ड के बजाय x होता है (यदि पासवर्ड मौजूद है, तो इसे / etc / छाया फ़ाइल में एन्क्रिप्ट किया जाएगा)। लेकिन निम्नलिखित दो क्षेत्रों में उपयोगकर्ता और समूह आईडी शामिल हैं। इस उदाहरण में ubuntu के मामले में, दोनों आईडी 1000 हैं। और व्यवस्थापक, जैसा कि आप देख सकते हैं, यहाँ शून्य है।

 $ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bash 

यदि आप कभी भी एक उपयोगकर्ता या समूह आईडी = 0 के साथ एक नियमित उपयोगकर्ता से मिलते हैं, तो आप यह आश्वासन दे सकते हैं कि मामला साफ नहीं है और स्थिति को ठीक करने की आवश्यकता है। इस तरह की समस्या की पहचान करने का एक त्वरित और आसान तरीका यह है कि आप awk कमांड के साथ passwd जाँच करें, जो कि तीसरे क्षेत्र की सभी पंक्तियों को प्रदर्शित करेगी जिसमें कुछ भी नहीं है, लेकिन 0. मेरे मामले में (आप साँस छोड़ते हैं) केवल एक ही ऐसी लाइन थी - रूट। आप $ 3 के साथ $ 4 को बदलकर इसे फिर से चला सकते हैं - यह समूह आईडी फ़ील्ड की जांच करेगा।

 $ awk -F: '($3 == “0”) {print}' /etc/passwd root:x:0:0:root:/root:/bin/bash 

सिस्टम संसाधन लेखा परीक्षा

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

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

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

पोर्ट स्कैन

यदि कोई होस्ट इस पोर्ट पर अनुरोधों को सुनता है तो एक पोर्ट को "ओपन" माना जाता है। अपने खुले बंदरगाहों पर नज़र रखते हुए, आप बेहतर समझ पाएंगे कि आपके सर्वर पर वास्तव में क्या हो रहा है।

आप पहले से ही जानते हैं कि HTTP (80) और SSH (22) पोर्ट शायद एक नियमित वेब सर्वर पर खुले होने चाहिए, इसलिए उन्होंने आपको आश्चर्यचकित नहीं किया। लेकिन अन्य, अप्रत्याशित परिणामों पर ध्यान देना बहुत अधिक महत्वपूर्ण है। नेटस्टैट कमांड सभी खुले बंदरगाहों को प्रदर्शित करता है, साथ ही साथ एक टन जानकारी के बारे में बताता है कि उनका उपयोग कैसे किया जाता है।

इस उदाहरण में, हम एक बहुत ही विशिष्ट बहुउद्देशीय सर्वर का परीक्षण कर रहे हैं, और एक कमांड सभी न्यूमेरिक पोर्ट और पते को सक्षम करने के लिए netstat को बताता है। -l केवल सुनने के सॉकेट शामिल हैं, और -p सुनने वाले प्रोग्राम की प्रक्रिया आईडी जोड़ता है। स्वाभाविक रूप से, यदि आप कुछ देखते हैं - कार्य।

 # netstat -npl Active Internet connections (only servers) Proto Local Address Foreign Address State PID/Program name tcp 127.0.0.1:3306 0.0.0.0:* LISTEN 403/mysqld tcp 0.0.0.0:139 0.0.0.0:* LISTEN 270/smbd tcp 0.0.0.0:22 0.0.0.0:* LISTEN 333/sshd tcp 0.0.0.0:445 0.0.0.0:* LISTEN 270/smbd tcp6 :::80 :::* LISTEN 417/apache2 […] 

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

 $ ss -o state established '( dport = :ssh or sport = :ssh )' Netid Recv-Q Send-Q Local Address:Port Peer Address:Port tcp 0 0 10.0.3.1:39874 10.0.3.96:ssh timer:(keepalive,18min,0) 

सक्रिय सेवाओं की जाँच करना

यदि आप system द्वारा प्रबंधित सेवाओं का त्वरित स्नैपशॉट लेते हैं और वर्तमान में आपके कंप्यूटर पर सक्रिय हैं, तो मशीन किसी भी अवांछित गतिविधि की पहचान करने में मदद करेगी। systemctl कमांड सभी मौजूदा सेवाओं को सूचीबद्ध कर सकती है, और फिर उनकी सूची को उन लोगों तक सीमित किया जा सकता है जिनके विवरण में enabled । इसलिए केवल सक्रिय सेवाओं को वापस किया जाएगा।

 # systemctl list-unit-files — type=service — state=enabled autovt@.service enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled getty@.service enabled haveged.service enabled mysql.service enabled networking.service enabled resolvconf.service enabled rsyslog.service enabled ssh.service enabled sshd.service enabled syslog.service enabled systemd-timesyncd.service enabled thermald.service enabled unattended-upgrades.service enabled ureadahead.service enabled 

यदि आपको ऐसा कुछ मिलता है जो स्पष्ट रूप से systemctl नहीं होता systemctl , तो आप सेवा को रोकने के लिए systemctl कमांड का उपयोग कर सकते हैं और सुनिश्चित कर सकते हैं कि यह अगले बूट पर पुनः आरंभ नहीं होता है।

 # systemctl stop haveged # systemctl disable haveged 

वास्तव में, haveged सेवा में अंधेरा और उदास कुछ भी नहीं है जिसे मैं इस उदाहरण में रोकता हूं: यह एक ऐसा उपकरण है जो मैं अक्सर एन्क्रिप्शन कुंजी बनाते समय यादृच्छिक पृष्ठभूमि सिस्टम गतिविधि बनाने के लिए चलाता हूं।
स्थापित कार्यक्रमों के लिए खोजें

क्या कोई आपकी जानकारी के बिना सिस्टम में प्रोग्राम इंस्टॉल कर सकता है? खैर, यह पता लगाने के लिए - आपको देखने की जरूरत है। yum list installed कमांड या, डेबियन / उबंटू के मामले में, dpkg — list आपको एक विस्तृत सारांश देगी, और हटाए गए कमांड को उन सभी पैकेजों को हटा देना चाहिए जिनकी हमें आवश्यकता नहीं है।

 # yum list installed # yum remove packageName 

यहाँ एक ही चीज़ उबंटू में की गई है:

 # dpkg --list # apt-get remove packageName 

आपके सिस्टम कॉन्फ़िगरेशन फ़ाइलों में किए जा रहे परिवर्तनों का ट्रैक रखना भी उपयोगी है - हम इस बारे में अध्याय 11 में बात करेंगे।