VPN पते पर बँधा NFS निर्यात: यह क्या सिद्ध नहीं करता
निर्यात नियम जाँचता है कि पैकेट कहाँ से आया; AUTH_SYS स्थानीय UID का दावा करता है और Kerberos उपयोगकर्ता को प्रमाणित करता है। तय करें कि आपकी फ़ाइल सेवा को कौन-सा चाहिए।
एक होस्ट किसी निर्देशिका को VPN पते पर निर्यात करता है, माउंट सफल होता है, और डिज़ाइन को प्रमाणित के रूप में दर्ज कर दिया जाता है। वह नियम वास्तव में केवल यह सीमित करता है कि पैकेट कहाँ से आते दिखते हैं। फ़ाइल क्रिया चलाने वाला व्यक्ति वही है जो वह होने का दावा करता है या नहीं, यह NFS सुरक्षा फ़्लेवर पर निर्भर करता है, और इस तरह के अधिकांश निर्यातों में किसी ने इसे डिफ़ॉल्ट से नहीं बदला।
एक अनुरोध में तीन पहचान आ सकती हैं
VPN सहकर्मी एक पंजीकृत पहचान रखता है, जैसे क्लाइंट प्रमाणपत्र या सहकर्मी कुंजी। भीतरी IP पैकेट एक स्रोत पता रखता है। फ़ाइल क्रिया वह उपयोगकर्ता क्रेडेंशियल रखती है जो उसका NFS तंत्र देता है। जो डिज़ाइन पते को तीनों का विकल्प मानता है, उसने चुपचाप वही हिस्सा मान लिया है जिसे सत्यापित करना था।
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
उन तीन पंक्तियों को लिखना ही पूरा अभ्यास है। निर्यात सुरक्षित है या नहीं, इस पर बहस का अधिकांश भाग तब ढह जाता है जब स्पष्ट हो जाता है कि कौन-सा नियंत्रण किस पंक्ति में रहता है।
पते का स्वामित्व कार्यान्वयन का विवरण है
एक गेटवे स्वीकृत सहकर्मी को टनल पता दे सकता है, या उसके लिए रूट किया गया सबनेट अधिकृत कर सकता है। उसके बाद कार्यान्वयन ऐसे पैकेट को अस्वीकार करता है या नहीं जिसका भीतरी स्रोत किसी दूसरे क्लाइंट का है, यह उस कार्यान्वयन का गुण है, और इसे मानने के बजाय जाँचना उचित है।
पारंपरिक Community OpenVPN उपयोगकर्ता-स्थान सर्वर कोड, उदाहरण के लिए, TUN उपकरण से पैकेट पहुँचाने से पहले किसी दूसरे क्लाइंट से जुड़े स्रोत को अस्वीकार कर सकता है। यह वास्तविक मूल्य वाली पता-स्वामित्व जाँच है, और यह अभी भी NFS उपयोगकर्ता प्रमाणीकरण नहीं है, क्योंकि यह नहीं बताती कि कौन-सा खाता यह क्रिया कर रहा है।
स्रोत अनुवाद इसको भी क्षीण करता है। एक NAT गेटवे हर क्लाइंट को एक ही पते के रूप में प्रस्तुत कर सकता है, और तब निर्यात नियम उसके पीछे के लोगों में भेद नहीं कर सकता। नियम की दिखने वाली सटीकता तब आरेख द्वारा बनाए रखी गई एक कल्पना बन जाती है। अगर निर्यात मायने रखता है, तो पता-निर्धारण स्पष्ट रखें, अनुवादक को यह तय करने न दें कि कौन किसका प्रतिनिधि गिना जाए।
निर्यात पर भरोसा करने से पहले सुरक्षा फ़्लेवर पढ़ें
Red Hat का NFS मार्गदर्शन sec=sys को, जो AUTH_SYS के माध्यम से स्थानीय UNIX UID और GID उपयोग करता है, Kerberos विधियों से अलग करता है। krb5 उपयोगकर्ता प्रमाणीकरण जोड़ता है, krb5i अखंडता सुरक्षा जोड़ता है, और krb5p ट्रैफ़िक के लिए गोपनीयता सुरक्षा जोड़ता है।
AUTH_SYS क्रेडेंशियल में कॉलर का UID और समूह पहचानकर्ता जैसे क्षेत्र होते हैं, और RFC 5531 स्पष्ट चेतावनी देता है कि यह फ़्लेवर अपने आप में कोई सुरक्षा नहीं देता और बाहरी सुरक्षा पर निर्भर है। इसे VPN के भीतर चलाने से परिवहन के लिए सुरक्षा मिलती है और पैकेट के भीतर के दावे में कुछ नहीं बदलता।
exportfs -v
showmount -e nfs.example.internalक्लाइंट सूची पढ़ने से पहले उस आउटपुट में फ़्लेवर पढ़ें। प्रतिबंधित दिखने वाला निर्यात केवल पते से प्रतिबंधित हो सकता है जबकि हर कॉलर अभी भी जो चाहे वह UID दावा करता है।
मॉडल चुनें, फिर अनुमतियाँ रखें
जिन क्लाइंटों को आप वास्तव में प्रशासित करते हैं उनके लिए उपयुक्त फ़ाइल-सेवा प्रमाणीकरण मॉडल चुनें। Kerberos को पीछे पहचान और सेवा परिनियोजन चाहिए, इसलिए एक माउंट विकल्प बदलना कोई माइग्रेशन नहीं है और तब तक केवल विफल होगा जब तक Kerberos डोमेन, प्रिंसिपल और keytab मौजूद न हों।
दोनों में से किसी भी मॉडल में, निर्यात अनुमतियाँ और फ़ाइलसिस्टम प्राधिकरण रखें जो प्रमाणित प्रिंसिपल की सीमा तय करते हैं। प्रमाणीकरण बताता है कि कौन पूछ रहा है; प्राधिकरण तय करता है कि उत्तर हाँ होना चाहिए या नहीं। इन दोनों को एक सेटिंग में मिला देना ही वह तरीका है जिससे माइग्रेशन पुरानी कॉन्फ़िगरेशन से अधिक अधिकार देने लगता है।
पता-नियम का उपयोग उसके असली उद्देश्य के लिए करें
सेवा को अनुमोदित पथ और स्रोतों तक सीमित करना अभी भी सार्थक है, जिसमें होस्ट इनपुट नीति भी शामिल है जब VPN एंडपॉइंट और NFS सर्वर एक ही मशीन साझा करते हैं। ट्रैफ़िक अग्रेषित करने वाले नियम उन अनुरोधों को नियंत्रित नहीं करते जो उसी होस्ट पर स्थानीय रूप से चल रही सेवा की ओर लक्षित हैं। यह अंतराल आश्चर्यजनक रूप से कई ऐसे निर्यात समझाता है जो निजी होने चाहिए थे। टनल नियमों के इसे कवर करने की मान्यता के बजाय स्थानीय इनपुट नीति स्पष्ट रूप से जाँचें।
जाँचें कि कोई दूसरा इंटरफ़ेस या स्रोत-अनुवाद करने वाला गेटवे अप्रत्याशित रूप से नियम पूरा नहीं कर सकता, और इसे पता जाली बनाने से कार्यशील माउंट की गारंटी होने के दावे के बजाय उद्गम स्थापित करने का कारण मानें।
एक के बजाय तीन स्वीकृति मामले चलाएँ। स्वीकृत क्लाइंट के साथ स्वीकृत उपयोगकर्ता के रूप में शुरू करें, फिर उस सहकर्मी से दोहराएँ जिसे कभी स्वीकृत नहीं किया गया, फिर कुछ ऐसा आज़माएँ जो स्वीकृत उपयोगकर्ता को अभी भी अनुमत नहीं है। बाद में पूछें कि यदि कोई अधिकृत क्लाइंट समझौता हो जाए तो क्या बदलता है, क्योंकि परिवहन प्रमाणीकरण उस मशीन पर हर प्रक्रिया को विश्वसनीय नहीं बनाता। चोरी हुआ प्रमाणपत्र और जिज्ञासु स्थानीय खाता अलग-अलग नियंत्रणों वाली अलग-अलग समस्याएँ हैं।