एक डेबियन सर्वर को सुरक्षित करने के लिए आप क्या कदम उठाते हैं? [बन्द है]

66

मैं एक डेबियन सर्वर स्थापित कर रहा हूं जो सीधे इंटरनेट से जुड़ा हुआ है। जाहिर है मैं इसे यथासंभव सुरक्षित बनाना चाहता हूं। मैं चाहूंगा कि आप लोग / gals इसे सुरक्षित करने के लिए अपने विचारों को जोड़ें और इसके लिए आप किन कार्यक्रमों का उपयोग करें।

मैं इस सवाल का हिस्सा चाहता हूं कि आप फ़ायरवॉल के रूप में क्या उपयोग करते हैं? बस iptables मैन्युअल रूप से कॉन्फ़िगर किया गया है या क्या आप आपकी सहायता के लिए किसी प्रकार के सॉफ़्टवेयर का उपयोग करते हैं? सबसे अच्छा तरीका क्या है? सब कुछ ब्लॉक करें और केवल वही दें जो आवश्यक है? क्या इस विषय के शुरुआती लोगों के लिए अच्छे ट्यूटोरियल हैं?

क्या आप अपना SSH पोर्ट बदलते हैं? क्या आप Bruteforce हमलों को रोकने के लिए Fail2Ban जैसे सॉफ़्टवेयर का उपयोग करते हैं ?

— पीटर मोर्टेंसन
स्रोत

1

वहाँ के साथ ओवरलैप के एक बहुत है serverfault.com/questions/42/securing-a-fresh-ubuntu-server और

— Zoredache

1

उबंटू UFW डेबियन नहीं है;) मैं woundering था कि लोग iptables को विन्यस्त थे उन्हें खुद या fireHOL जैसे कुछ सॉफ्टवेयर का उपयोग कर

— Thomaschaaf

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

— स्कॉट पैक

3

उम्म ... डेबियन में ufw है। packages.debian.org/ufw

— Womble

50

अनिवार्य:

विशेषज्ञ मोड के साथ सिस्टम की स्थापना, केवल पैकेज जो मुझे चाहिए
iptables'input पर डिफ़ॉल्ट नीति के साथ हाथ से लिखा फ़ायरवॉल: ड्रॉप, एसएसएच, एचटीटीपी तक पहुंच की अनुमति या जो भी दिया गया सर्वर चल रहा है
SSH के लिए Fail2Ban [और कभी-कभी FTP / HTTP / अन्य - संदर्भ के आधार पर]
रूट लॉगिन अक्षम करें, सामान्य उपयोगकर्ता और sudo का उपयोग कर बल
कस्टम कर्नेल [बस पुरानी आदत]
शेड्यूल किया गया सिस्टम अपग्रेड

समान रूप से व्यामोह के स्तर पर निर्भर करता है:

अनुमति गंतव्य / बंदरगाहों के एक जोड़े को छोड़कर उत्पादन पर नीति छोड़ दें
integritजाँच के लिए अगर फ़ाइल सिस्टम वेयर के कुछ हिस्सों को संशोधित नहीं किया गया है [मशीन के बाहर रखे चेकसम के साथ], उदाहरण के लिए ट्रिपवायर
कम से कम बाहर से सिस्टम के नैप के साथ अनुसूचित स्कैन
अज्ञात पैटर्न के लिए स्वचालित लॉग चेकिंग [लेकिन यह ज्यादातर हार्डवेयर खराबी या कुछ छोटी दुर्घटनाओं का पता लगाने के लिए है]
के निर्धारित रन chkrootkit
/etc/passwdनए उपयोगकर्ताओं को जोड़ने के लिए अपरिवर्तनीय विशेषता थोड़ी अधिक कठिन है
/ tmp noexec के साथ मुहिम शुरू की
बंदरगाह खटखटाने या एसएसएच पोर्ट खोलने के अन्य गैर-मानक तरीके [जैसे कि वेब सर्वर पर 'गुप्त' वेब पेज पर जाकर आने वाले एसएसएच कनेक्शन को आईपी पते से सीमित अवधि के लिए आने वाले समय में देखा जा सकता है। यदि आप कनेक्ट होते हैं, -m state --satete ESTABLISHEDतो पैकेट प्रवाह को अनुमति देने का ध्यान रखते हैं , जब तक आप एक एकल SSH सत्र का उपयोग करते हैं]

चीजें जो मैं खुद नहीं करता लेकिन समझ में आता है:

कर्नेल के लिए आभार
जब सिस्टम समझौता कर लेता है तो दूरस्थ syslog इसलिए लॉग को अधिलेखित नहीं किया जा सकता है
किसी भी SSH लॉगिन के बारे में चेतावनी देना
rkhunter को कॉन्फ़िगर करें और इसे समय-समय पर चलाने के लिए सेट करें

— pQd
स्रोत

4

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

— स्कॉट पैक

13

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

— एडम गिबिन्स

3

अस्पष्टता के माध्यम से सुरक्षा के लिए -1। अन्यथा सभ्य जवाब।

— DWC

@ एडम - हाँ, मुझे पता है कि, अभी भी मैं अखंड कर्नेल को पसंद करता हूं, जिसमें केवल कुछ ऐसे हिस्से होते हैं जिनकी मुझे आवश्यकता होती है। वह शायद बहुत पिछड़ा हुआ है, लेकिन फिर भी मैं ऐसा करता हूं। @dwc - यह सिर्फ एक अतिरिक्त कदम है जो सिर्फ एक टुकड़े के रूप में है या जैसा कि हम अप्रिय स्माइल चीजों के ढेर के शीर्ष पर चेरी कहते हैं।

— पीक्यूडी

1

और आप

— सूदो का

18

बस अपनी मशीन को फायरवॉल पर एक नोट ...

एक श्वेतसूची का उपयोग करें, एक ब्लैकलिस्ट नहीं - यानी सब कुछ ब्लॉक करें, और केवल वही करें जो आपको चाहिए, बाकी सब से इनकार करें।
GUIs / ncurses या किसी भी सॉफ़्टवेयर का उपयोग न करें जो आपके लिए अपने फ़ायरवॉल को लिखने का कार्य करने का प्रयास करता है। यदि आप करते हैं, तो आप सॉफ्टवेयर को आपके लिए धारणा बनाने की अनुमति देंगे - आपको उस जोखिम को लेने की जरूरत नहीं है और न ही करना चाहिए। इसे स्वयं कॉन्फ़िगर करें, यदि आप अनिश्चित हैं, तो इसे अक्षम करें - यदि आवश्यक हो तो आपको जल्द ही पता चल जाएगा। यदि यह पहले से ही एक अप और रनिंग सिस्टम है और आप ट्रैफ़िक को बाधित नहीं कर सकते हैं (गलती से इसे रोककर), तो tcpdump (फाइल करने के लिए डंप) और नमूने लें - बाद में उनका अध्ययन करें, और फिर पता लगाएँ कि क्या मान्य है और क्या नहीं।
मैं व्यक्तिगत रूप से एक गैर-मानक पोर्ट पर सेवा चलाने के लिए कोई बिंदु नहीं देखता हूं, इन दिनों यह मानने के लिए उपकरण इतने गूंगे नहीं हैं कि क्योंकि कोई चीज उदाहरण के लिए पोर्ट 22 पर चल रही है, तो यह ssh होना चाहिए, और अन्यथा नहीं - के लिए उदाहरण के amapलिए, और nmapके -Aविकल्प। कहा जा रहा है कि, आप कर सकते हैं (और शायद अगर चिंतित होना चाहिए) अपनी सेवाओं को संशोधित करने के लिए खुद को prying आँखों से छिपाने के लिए, उदाहरण के लिए, निम्नलिखित हमलावर को पता OpenSSHचल जाएगा कि आप चल रहे हैं के सटीक संस्करण , वे तो कारनामे के लिए देख सकते हैं वह सटीक संस्करण। यदि आप ऐसी चीजों को छिपाते हैं, तो आप उनके लिए कठिन बना देंगे।

    [रूट @ ud-olis-1 uhtbin] # टेलनेट लोकलहोस्ट २२
    127.0.0.1 की कोशिश कर रहा है ...
    Localhost.localdomain (127.0.0.1) से जुड़ा।
    पलायन चरित्र '^] है।
    SSH-2.0-OpenSSH_3.9p1

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

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

iptables किसी भी लिनक्स सिस्टम के लिए जाने का तरीका है - लेकिन इसे स्वयं कॉन्फ़िगर करें।

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

उम्मीद है की वो मदद करदे :)

— ज़ैक्सीस
स्रोत

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

— L0neRanger

12

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

— एक्स-तरफा
स्रोत

आपको पासवर्ड को अक्षम करने के लिए upvote मिलता है।

— जुआर

9

यहाँ से प्रारंभ करें:

http://www.debian.org/doc/manuals/securing-debian-howto/

— KPWINC
स्रोत

1

डेबियन सिक्योरिटी मैनुअल एक शानदार संसाधन है।

6

एक सामान्य शुरुआती बिंदु के रूप में, मैं सेंटर फॉर इंटरनेट सिक्योरिटी के बेंचमार्क / गाइड का पालन करता हूं , जो सुरक्षा सर्वोत्तम प्रथाओं के व्यापक संकलन हैं। ऐसा नहीं लगता है कि उनके डेबियन बेंचमार्क को कुछ समय में अपडेट किया गया है, लेकिन चरणों का एक सामान्य अवलोकन है:

नवीनतम OS पैच / पैकेज लागू करें
सिस्टम / कर्नेल / प्रोसेस अकाउंटिंग सक्षम करें।
मैक सक्षम करें (जैसे, SELinux या AppArmor)।
होस्ट-आधारित फ़ायरवॉल (iptables) सक्षम करें।
APT source.list को सत्यापित करें (चाबियाँ सही हैं, स्रोत विश्वसनीय हैं)।
नेटवर्क सेवाओं को कम से कम करें, आवश्यक सब कुछ अक्षम करें, और फ़ायरवॉल क्या है।
सिस्टम की पहुँच को और प्रतिबंधित करने के लिए TCPWrappers का उपयोग करें।
केवल एन्क्रिप्टेड नेटवर्क प्रोटोकॉल का उपयोग करें, अनएन्क्रिप्टेड सेवाओं को अक्षम करें (टेलनेट, एफटीपी, आदि)।
केवल SSH के लिए दूरस्थ पहुँच कॉन्फ़िगर करें।
उपयोगकर्ता लॉगिन पासवर्ड अक्षम करें और कुंजी-आधारित प्रमाणीकरण की आवश्यकता है।
फ़ाइल सिस्टम साझाकरण अक्षम करें (NFS, SMB)।
दूरस्थ / केंद्रीकृत सिस्टम लॉगिंग सक्षम करें (और नियमित रूप से लॉग की समीक्षा करें!)।
एक BIOS / फर्मवेयर स्तर का पासवर्ड सेट करें।
एक बूटलोडर पासवर्ड सेट करें।
सिस्टम बैकअप कॉन्फ़िगर करें, एक आपदा पुनर्प्राप्ति योजना है और परीक्षण कि बैकअप मान्य हैं, और यह कि कर्मियों को आपदा वसूली प्रक्रियाएं पता हैं!

इन सभी विभिन्न सेटिंग्स पर कई संसाधन हैं, जिसमें CISecurity बेंचमार्क में सिस्टम पर लागू करने के लिए विशिष्ट कमांड और कॉन्फ़िगरेशन फाइलें शामिल हैं।

— jtimberman
स्रोत

5

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

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

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

सुरक्षा दो हाइकर्स और भालू के बारे में मजाक की तरह है - जबकि कोई कभी भी पूर्ण सुरक्षा प्राप्त नहीं कर सकता है, यह अन्य लोगों की तुलना में अधिक कठिन लक्ष्य होने में मददगार है।

— pcapademic
स्रोत

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

— DWC

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

— pcap शैक्षणिक

4

कुछ लोगों ने सिक्योरिंग डेबियन मैनुअल की ओर इशारा किया है । यह सब कुछ लेकिन सैन्य आवश्यकताओं के लिए पूरी तरह से पर्याप्त होना चाहिए।

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

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

मैं अपने सभी सर्वरों के लिए फुल-डिस्क एन्क्रिप्शन में बदलने की प्रक्रिया में हूं।

मैं केवल उन सेवाओं को स्थापित करता हूं जिनका मैं उपयोग करता हूं। मेरे पास फ़ायरवॉल नहीं है; मुझे उन सेवाओं को कॉन्फ़िगर करना होगा जिनके लिए मुझे प्रमाणीकरण की आवश्यकता है या उन्हें (प्रोग्राम के स्वयं के कॉन्फ़िगरेशन या टीसीपी-रैपर द्वारा) कुछ आईपीओं तक सीमित करना है। केवल एक चीज जिसे मुझे iptables का उपयोग करके ब्लॉक करने की आवश्यकता थी memcached, क्योंकि इसमें कोई कॉन्फ़िगरेशन फ़ाइल नहीं थी, और टीसीपी-रैपर का उपयोग नहीं किया था।

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

— टेडी
स्रोत

3

Www.debian.org/doc/manuals/securing-debian-howto/ पर इस अच्छे से कैसे जाएं

मैं व्यक्तिगत रूप से ssh पोर्ट को बदलता हूं और fail2ban + denyhosts का उपयोग करता हूं। और मैं वह सब कुछ ब्लॉक करता हूं जिसकी जरूरत नहीं है। आप जितना कम ब्लॉक करेंगे आपको चिंता करनी होगी।

— विहंग डी
स्रोत

4

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

— मैट सिमंस

3

हां, मुझे पता है कि कोई भी आपको स्कैन कर सकता है, और सही पोर्ट का पता लगा सकता है। लेकिन ज्यादातर हमले डिफ़ॉल्ट पोर्ट पर होते हैं। बस पोर्ट को बदलकर कुछ आंकड़े प्राप्त करने का प्रयास करें।

— विहंग डी