लिनक्स के लिए सुरक्षित नेटवर्क फाइलसिस्टम: लोग क्या कर रहे हैं?


26

NFSv3 व्यापक है, लेकिन डिफ़ॉल्ट सुरक्षा मॉडल है ... विचित्र । CIFS कर्बेरॉस प्रमाणीकरण का उपयोग कर सकता है, लेकिन POSIX शब्दार्थ के बिना यह एक गैर स्टार्टर है। AFS ने तार पर ट्रैफ़िक को कभी एन्क्रिप्ट नहीं किया और krb4 है - और मूल रूप से एक मृत परियोजना है। फैंसी नए प्रायोगिक फाइल सिस्टम या तो कभी भी गति नहीं देते हैं या गति पर ध्यान केंद्रित करते हैं (और यदि आप भाग्यशाली हैं, तो डेटा विश्वसनीयता) - उदाहरण के लिए, लस्टर उसी क्लाइंट-ट्रस्ट मॉडल का उपयोग करता है जैसे कि एनएफएसवी 3। घर में उपयोग के लिए, sshfs निफ्टी है, लेकिन यह सुनिश्चित नहीं है कि पैमाने नहीं हैं।

और फिर निश्चित रूप से NFSv4, sec = krb5p के साथ है। सिद्धांत रूप में महान, लेकिन दस वर्षों के बाद, यह वास्तविक दुनिया में परेशान अप्रयुक्त प्रतीत होता है। लिनक्स क्लाइंट के पास अभी प्रयोगात्मक टैग हटा दिया गया है। और अगर आप EMC Celerra, Isilon आदि को देखते हैं, तो यह सभी NFSv3 है। (Celerra NFSv4 का समर्थन करता है, लेकिन यह वास्तव में प्रलेखन में दफन है। Isilon ने स्पष्ट रूप से RPCGSS समर्थन को FreeBSD में जोड़ने का काम किया है, इसलिए शायद यह आ रहा है, लेकिन यह अभी नहीं है।) मैं इस पोस्ट को "nfsv4" के रूप में टैग भी नहीं कर सकता क्योंकि "मैं। यहाँ नया है और यह एक नया टैग होगा

तो, वास्तव में । तुम सब क्या कर रहे हो?


मैं कहना चाहूंगा, "IPSEC पर NFS3", लेकिन मैं नहीं कर सकता।
sysadmin1138

1
"IFSEC पर NFS3" ऑन-द-वायर मुद्दे के साथ मदद करता है, लेकिन एक और मौलिक एनएफएस समस्या को संबोधित नहीं करता है: यदि एक क्लाइंट बॉक्स रूट हो जाता है, या यदि आप ऐसे वातावरण में हैं जहां उपयोगकर्ता अपने सिस्टम पर रूट करते हैं, तो वे किसी भी दूरस्थ उपयोगकर्ता को तुच्छ रूप से प्रतिरूपित कर सकता है।
Mattdm

वहाँ आप हैं, नया टैग;)
क्राओ हैवॉक

1
AFAIK, कर्बेरोस को NFS के लिए परिभाषित किया गया
जेवियर

2
मैं लैन वातावरण में तार पर यातायात को एन्क्रिप्ट करने की आवश्यकता के बारे में इतना निश्चित नहीं हूं (प्रमाणीकरण को हालांकि एन्क्रिप्ट किया जाना चाहिए)। आप ARP विषाक्तता के लिए वैसे भी निगरानी करना चाहिए ...
ह्यूबर्ट करियो

जवाबों:


8

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

उन डेटा के लिए जिन्हें आप वास्तव में पढ़ना नहीं चाहते हैं, आप उन्हें स्पष्ट रूप से एन्क्रिप्ट करते हैं, जैसे फ़ायरफ़ॉक्स पासवर्ड डेटाबेस, ssh कुंजियाँ, या pgp कुंजियाँ। आप ऐसा इसलिए करते हैं क्योंकि आप जानते हैं कि व्यवस्थापक उन्हें फ़ाइल सर्वर पर पढ़ सकते हैं, इसलिए नेटवर्क फ़ाइल सिस्टम सुरक्षा किसी भी तरह की मदद नहीं करेगी।


14

आप यहाँ दो सवाल पूछ रहे हैं:

हम वास्तव में क्या उपयोग कर रहे हैं? और यह क्या करता है?

क्या मैं कर रहा हूँ वास्तव में का उपयोग कर CIFS है, मेरे उपयोग-मामले में POSIX कम महत्वपूर्ण है इसलिए मैं कोई समस्या नहीं है था। NFS3 का उपयोग उन क्षेत्रों में किया जाता है जहां सुरक्षा महत्वपूर्ण नहीं है, जैसे कि मेरा SLES सर्वर स्थापित करना। और अंत में, सरल उपयोगकर्ता-भूमि साझा करने के लिए sshfs / gvfs। वायरलाइन एन्क्रिप्शन की आवश्यकता नहीं समझी जाती है, इसलिए यह हमारे लिए एक सार्थक कारक नहीं है।

दूसरे प्रश्न के लिए, आप जो खोज रहे हैं, उसके लिए छह मुख्य आवश्यकताएं हैं:

  1. तार पर यातायात को प्रोत्साहित करता है।
  2. प्रमाणीकरण को प्रोत्साहित करता है।
  3. पॉज़िक्स शब्दार्थ।
  4. सर्वर-आधारित एसीएल का मजबूत प्रवर्तन।
  5. उपयोगकर्ता नहीं है।
  6. वास्तव में उपयोग किया जाता है।

मुझे संदेह है कि अंक 5 और 6 यहां हत्यारे होंगे, लेकिन यहां जाता है (यह भी, यह वह बिंदु है जहां एक तालिका वास्तव में आसान होगी, लेकिन markdown / StackExchange इसका समर्थन नहीं करता है)।

NFSv3 + IPSec

  1. तार पर एन्क्रिप्टेड, पास
  2. कोई एन्क्रिप्टेड प्रमाणीकरण, विफल
  3. पॉज़िक्स शब्दार्थ, पास
  4. सर्वर-आधारित ACL का कोई मजबूत प्रवर्तन विफल हो जाता है
  5. यूजरलैंड नहीं है, पास है
  6. वास्तव में उपयोग किया जाता है, पास

NFSv4 + Krb + IPSec

  1. तार पर एन्क्रिप्टेड, पास
  2. एन्क्रिप्टेड प्रमाणीकरण, पास
  3. पॉज़िक्स शब्दार्थ, पास
  4. सर्वर-आधारित एसीएल का सशक्त प्रवर्तन, पास
  5. यूजरलैंड नहीं है, पास है
  6. वास्तव में उपयोग नहीं किया जाता है, असफल

CIFS

  1. तार पर एन्क्रिप्टेड नहीं, विफल
  2. एन्क्रिप्टेड प्रमाणीकरण
  3. पॉज़िक्स शब्दार्थ, पास (सांबा और कर्नेल अब, विंडोज़ में NT दिनों से एक पॉज़िक्स परत है)
  4. सर्वर-आधारित एसीएल का सशक्त प्रवर्तन, पास
  5. यूजरलैंड नहीं है, पास है
  6. वास्तव में उपयोग किया जाता है, पास

CIFS + IPSec

  1. तार पर एन्क्रिप्टेड, पास
  2. एन्क्रिप्टेड प्रमाणीकरण
  3. पॉज़िक्स शब्दार्थ, पास (सांबा और कर्नेल अब)
  4. सर्वर-आधारित एसीएल का सशक्त प्रवर्तन, पास
  5. यूजरलैंड नहीं है, पास है
  6. वास्तव में उपयोग नहीं किया जाता है, असफल

sshfs

  1. तार पर एन्क्रिप्टेड, पास
  2. एन्क्रिप्टेड प्रमाणीकरण, पास
  3. पॉज़िक्स शब्दार्थ, पास
  4. सर्वर-आधारित एसीएल का सशक्त प्रवर्तन, पास
  5. उपयोगकर्ता है, विफल
  6. वास्तव में उपयोग किया जाता है, पास

एएफपी / netatalk

  1. तार पर एन्क्रिप्ट किया गया, विफल
  2. एन्क्रिप्टेड प्रमाणीकरण, पास
  3. पॉज़िक्स शब्दार्थ, पास
  4. सर्वर-आधारित एसीएल का सशक्त प्रवर्तन, पास
  5. यूजरलैंड नहीं है, पास है
  6. वास्तव में उपयोग किया जाता है, असफल

और मैं वहाँ वितरित फ़ाइल-सिस्टम को नहीं छू रहा हूँ। वहाँ बस एक ही बात नहीं है कि यह सब करता है। कुछ पास आते हैं (CIFS) और कुछ पहले से ही हैं, लेकिन कोई भी उनका उपयोग नहीं करता है (NFS4 + IPSec, CIFS + IPSec)। किसी कारण से एक सुरक्षित नेटवर्क फाइलसिस्टम ऐसा कुछ है जो वर्षों में बहुत सारे समझौते के अधीन है।


आप "NFSv4 + Krb" का उल्लेख कर सकते हैं और कहा कि "7. क्या यह काफी तेजी से है (यानी एन्क्रिप्शन के बिना एक ही प्रोटोकॉल स्टैक की तुलना में)?" एक सवाल के रूप में। जो शायद NFSv4 + krb5p के लिए असफल होगा , लेकिन प्रश्नों के लिए 1-6 पास करें
अल।

एक नए सुरक्षित नेटवर्क फाइल सिस्टम SNFS के लिए समय हो सकता है?
Unix Janitor

@ user37899 समस्या, हमेशा की तरह, उपकरण विक्रेताओं को इसका समर्थन करने के लिए आश्वस्त कर रही है, और संगठन इसे तैनात करने के लिए।
sysadmin1138

1
हमारे पास POSIX मोड में CIFS का उपयोग करने की कोशिश में वास्तव में बुरी किस्मत थी। शायद यह फिर से आने का समय है।
mattdm

FWIW मैं CIFS + IPsec का उपयोग कर रहा हूं, लेकिन POSIX शब्दार्थ के साथ नहीं। सर्वर emc celerra, क्लाइंट win7 है। ipsec सुरंगों को सिस्को एएसए (सेलेर्रा के बगल में) और win7 बिलिन ipsec के बीच लैन-टू-लैन मोड में किया जाता है।
दान प्रीत

3

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

एक चीज जो मुझे विशेष रूप से पसंद है वह है ओपनफ्स पर प्रोडक्शन इंटरनेट-फेसिंग वेब सर्वर चलाना, जिसमें एसीएल नीचे बंद हैं। केर्बरोस टिकट के बिना मशीन पर कोई प्रक्रिया नहीं है - यहां तक ​​कि रूट के रूप में चलने वाला - जो कि फाइलसिस्टम को लिख सकता है। मैं गणना नहीं कर सकता कि हमने कितनी बार देखा है कि हमलों को उस सरल उपाय के कारण पूरी तरह से विफल कर दिया गया है।

कुछ बहुत बड़े ओपनएफ़ उपयोगकर्ता हैं - सबसे बड़ा व्यावसायिक उपयोगकर्ता जो मुझे पता है कि मॉर्गन स्टेनली है।


1

कैसे OpenAFS के बारे में जो अभी भी जीवित है और इसके तहत एक वीपीएन है क्योंकि इस समय इसका एकमात्र एन्क्रिप्शन डेस है।


2
मैंने उत्पादन में OpenAFS का उपयोग किया है। इसके एलियन की अफवाहों को बहुत बढ़ा-चढ़ा कर पेश किया जाता है।
परिपक्वता

इस महीने में नई रिलीज़ हुई है और इससे पहले विंडोज के नए संस्करणों और लिनक्स कर्नेल के नए संस्करणों (नवीनतम रिलीज़ 3.0 का समर्थन करता है) का समर्थन करने के लिए काफी नियमित अपडेट हुए हैं।
ह्यूबर्ट करियो सेप

1

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


IPsec पर NFS उस (विस्तृत क्षेत्र लिंक पर) का ध्यान रखता है और ARP विषाक्तता की निगरानी लैन पर करता है
ह्यूबर्ट करियो

क्या कोई वास्तव में सफलता के साथ ipsec का उपयोग कर रहा है?
यूनिक्स Janitor

1

ठीक है, मेरे लिए यह उन डिस्ट्रीब्यूटेड फाइलसिस्टम में से एक है, जो आपके लिए होगा। मैं काफी ओपनएएफएस की सिफारिश नहीं करना चाहता, क्योंकि यह पुराना है, आईपीवी 6 का समर्थन नहीं करता है, ..

मैं खुद ग्लस्टरएफएस से काफी खुश हूं। चमक काफी परिपक्व है, ठीक प्रदर्शन करती है और इसमें एक अच्छी सुविधा है। हालांकि, जैसा कि हाल ही में आईआरसी में चर्चा की गई है, ग्लस्टर भी स्थिर तरीके से आईपीवी 6 का समर्थन नहीं करता है। यह सुविधा 3.6 या 3.7 के लिए निर्धारित की जाएगी।

HekaFS नामक एक परियोजना भी है, जो Gluster पर निर्मित होती है, जो अधिक उन्नत प्रमाणीकरण सुविधाएँ और SSL जोड़ता है। यह बहुत अच्छी तरह से प्रलेखित है और बहुत अच्छी तरह से डिज़ाइन किया गया है।

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

दोनों निश्चित रूप से सकारात्मक हैं।


0

मैं NFS का उपयोग करता हूं। लेकिन सर्वर से सर्वर एनएफएस एक समर्पित नेटवर्क बैकबोन पर किया जाता है ताकि एन्क्रिप्शन की आवश्यकता न हो और प्रमाणीकरण व्यर्थ की तरह हो। प्रत्येक निर्यात को केवल IP पर आधारित सर्वर के लिए एक चयनित निर्देशिका को साझा करने के लिए सेट करें।


समर्पित नेटवर्क, जब तक कि कोई व्यक्ति वायरहार्क के साथ रैक स्विच में जैक नहीं करता।
यूनिक्स जेनरेटर

यह एक शारीरिक सुरक्षा समस्या है। एक बार जब वे सर्वर के साथ एक ही कमरे में होते हैं, तो यह वैसे भी खेल है।
पोर्च

-2

सभी उचित सम्मान के साथ, आप पूरी तरह से इस समस्या को गलत तरीके से देख रहे हैं और आपको कुछ घंटों के लिए कंसोल से दूर होना चाहिए।

बहुत ज्यादा सारा स्टोरेज io अनएन्क्रिप्टेड है क्योंकि यह एब्सट्रैक्ट स्टैक की परत पर कोई फर्क नहीं पड़ता। मुझे शक है? अपने ब्रोकेड फाइबर स्विच पर एक नल लगाएं और आप देखेंगे कि फाइबर चैनल, जैसे इस्की और एनएफएस, सभी एक अनएन्क्रिप्टेड मेस है - डिजाइन द्वारा। समाधान एक मध्यम समस्या है, न कि भंडारण प्रोटोकॉल समस्या। उदाहरण के लिए, सुरक्षित और एन्क्रिप्टेड nfs चाहते हैं? Ipsec / ssl / tls या एक शुद्ध हार्डवेयर समाधान का उपयोग करके nfs क्लाइंट और सर्वर के बीच इंगित करने के लिए एन्क्रिप्टेड बिंदु एक लैन बनाया गया।


मुझे लगता है कि आपको एक महत्वपूर्ण बिंदु याद आ रहा है। जैसा कि सवाल कहता है, समस्या एनएफएस सुरक्षा मॉडल के साथ है। जबकि एन्क्रिप्शन अच्छा है, जैसा कि आप कहते हैं, यह एक समस्या है। एनएफएस के साथ बड़ी समस्या यह है कि एक बार सिस्टम पर एक फाइलसिस्टम आरोहित हो जाने के बाद, उस सिस्टम पर रूट एक्सेस वाला कोई भी व्यक्ति स्वामित्व या अनुमति की परवाह किए बिना उस फाइलसिस्टम पर किसी भी फाइल को एक्सेस कर सकता है। AFS जैसी प्रणाली या, सिद्धांत में, NFSv4 sec = krbp5 के साथ, फ़ाइलों तक पहुंचने के लिए मजबूत क्रेडेंशियल्स की आवश्यकता होती है, और इसलिए सुरक्षा में पर्याप्त वृद्धि का प्रतिनिधित्व करता है। एक मूल NFS क्लाइंट एक बड़े डेटा एक्सपोज़र की बराबरी नहीं करता है।
13

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

@BillThor यह वही है जो मैं सोच रहा था .. क्या यह अभी भी हमला करने के लिए खुला है अगर क्रेडेंशियल्स कर्नेल मेमोरी में हैं? मुझे लगता है कि कर्नेल मेमोरी के किसी भी टुकड़े को पढ़ने के लिए एक कर्नेल मॉड्यूल को लोड किया जा सकता है।
रोब ओल्मोस

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

2
@BillThor: kerberos के साथ, जोखिम को काफी कम कर दिया गया है, क्योंकि हमलावर केवल उन उपयोगकर्ताओं के फाइल सिस्टम तक पहुंच प्राप्त करेगा, जिन्होंने अपने टिकटों को अग्रेषित किया है, और केवल उन टिकटों के जीवनकाल के लिए। सिस्टम-आधारित प्रमाणीकरण (एक ला nfsv3) के साथ, रूट किसी भी उपयोगकर्ता की फ़ाइलों तक पहुंच और हेरफेर कर सकता है , भले ही उस उपयोगकर्ता का समझौता प्रणाली के साथ कोई लेना-देना न हो।
3
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.