SECLEVEL=0 लक्षण बरे करते, प्रमाणपत्र नाही

OpenVPN कनेक्शन अयशस्वी होते, कोणाला SECLEVEL=0 जोडणारी एक ओळीची दुरुस्ती सापडते आणि बोगदा वर येतो। बदलले ते प्रमाणपत्र नव्हते आणि सिफर संचही नव्हता; लायब्ररीभरची स्वीकृती उंबरठा सरकला, आणि प्रक्रिया त्यानंतर जे काही करते ते सर्व नवी सीमा वारसाहक्काने घेते। तीच ओळ पर्यावरणातील प्रत्येक प्रोफाइलमध्ये कॉपी होण्यापूर्वी हे समजून घेणे योग्य आहे।

कोणती लायब्ररी आणि कोणती धोरणे लागू आहेत ते ठरवा

SECLEVEL ही OpenSSL ची संकल्पना आहे, म्हणून पहिला प्रश्न असा की तुमचा बिल्ड OpenSSL वापरतो का। OpenVPN एकापेक्षा जास्त क्रिप्टोग्राफी लायब्ररींशी जोडले जाऊ शकते, आणि त्यापैकी एकाला लागू असलेली सेटिंग इतरांसाठी निरर्थक आहे। बाइनरीला कशाने तयार झाले ते विचारा, नंतर लायब्ररीला कोणती आवृत्ती आणि कॉन्फिगरेशन लोड केले ते विचारा:

openvpn --version | head -3
openssl version -a

आवृत्तीचे आउटपुट काळजीपूर्वक वाचा, कारण वितरणे डीफॉल्ट पॅच करतात। काही अशी सिस्टम कॉन्फिगरेशन देतात जी किमान पातळी अपस्ट्रीम डीफॉल्टच्या वर उचलते, आणि म्हणूनच एकाच OpenVPN पॅकेजेस असलेल्या दोन मशीनवर तेच प्रोफाइल वेगळे वागते। प्रभावी धोरण तेच आहे जे चालू प्रक्रियेने लोड केले, अपस्ट्रीम मॅन्युअलमधील नाही।

मग लोक ज्या दोन स्तरांची गल्लत करतात ते वेगळे करा। OpenVPN चे स्वतःचे TLS नियंत्रण आहेत, त्यात प्रमाणपत्र प्रोफाइल सेटिंग आणि स्पष्ट सिफर याद्या आहेत, आणि त्या लायब्ररी जे लादते त्याच्या वर बसतात। लायब्ररीची पातळी कमी केल्याने तुमचे OpenVPN कॉन्फिगरेशन कोणते सिफर सूचीबद्ध करते ते बदलत नाही, आणि OpenVPN यादी अरुंद केल्याने लायब्ररीचा उंबरठा वाढत नाही। कोणत्या स्तराने तुम्हाला नाकारले हे जाणणे हेच दुरुस्ती अंदाज राहू न देण्याचे कारण आहे।

नाकारले जाऊ शकणाऱ्या तीन गोष्टी वेगळ्या करा

पहिला उमेदवार ओळख सामग्री आहे: ज्याची किल्ली खूप लहान आहे किंवा ज्याचा स्वाक्षरी अल्गोरिदम धोरण आता स्वीकारत नाही असे प्रमाणपत्र। दुसरा किल्ली-देवघेव पॅरामीटर आहे, जसे की धोरणाला खूप कमकुवत वाटणारा गट। तिसरा धोरण वगळते असा सिफर संच आहे। तिन्ही हँडशेक अयशस्वीता निर्माण करू शकतात, आणि फक्त त्रुटी मजकूर आणि वाटाघाटीचा टप्पा त्यांना वेगळे करतो।

यापैकी कोणतेही डेटा-चॅनेलचे सिफर नाही। OpenVPN त्याचे बोगदा एन्क्रिप्शन TLS हँडशेकपासून वेगळे बोलणी करते, म्हणून सुरक्षा पातळी बदलल्यानंतर यशस्वी होणारे कनेक्शन तुमचा पेलोड कोणते सिफर संरक्षित करते याबद्दल काहीही सांगत नाही। तुम्ही खरोखर विचारत असलेला प्रश्न डेटाच्या गोपनीयतेबद्दल असल्यास, तुम्ही पूर्णपणे चुकीचा नियंत्रक पाहत आहात।

पातळी कमी केल्याने तीनही इनपुटसाठी स्वीकृती एकाच वेळी व्यापक होते। हाच तो भाग जो लोक चुकवतात: जुने प्रमाणपत्र स्वीकारणारी दुरुस्ती कमकुवत गट आणि तुम्ही कदाचित परवानगी देण्याचा विचार न केलेला संचही स्वीकारते। एका त्रुटीमुळे बदल घडला, आणि बदल त्रुटीपेक्षा व्यापक आहे। ही विषमताच मर्यादित अपवाद संपूर्ण पर्यावरणाच्या डीफॉल्टपेक्षा चांगला असण्याचे कारण आहे।

इनपुट बदला, उंबरठा नाही

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

नाकारलेले इनपुट तुम्ही नियंत्रित न करता त्या सहकाऱ्याचे असल्यास, बोलणी त्या सहकाऱ्याच्या मालकाशी समर्थित बदली सामग्रीबद्दल होते। कोणीही सांभाळत नसलेल्या प्रणालीची जागा करण्यासाठी स्वतःचा उंबरठा कमी करणे खर्च त्यांच्याकडून त्यांच्या नंतर जोडणाऱ्या सर्वांकडे सरकवते।

सर्व्हर धोरण लागू करतो तेथे, लायब्ररीला दोष देण्यापूर्वी OpenVPN-स्तरीय सेटिंग हेच खरे कारण आहे का ते तपासा। तैनात प्रमाणपत्र पूर्ण करू शकत नाही अशी कडक श्रेणी मागणारे प्रमाणपत्र प्रोफाइल सुरक्षा पातळी काहीही असो अयशस्वी होईल, आणि ते प्रोफाइल काढणे लायब्ररीच्या तपासण्या बंद करण्यापेक्षा अरुंद बदल आहे।

कमी करावेच लागल्यास, मर्यादित करा आणि नोंदवा

कधीकधी मंजूर सुसंगतता अपवाद हेच योग्य उत्तर असते, विशेषतः तारखेच्या निवृत्ती योजनेसह जुन्या सहकाऱ्यासाठी। तो संपूर्ण होस्टऐवजी त्याची गरज असलेल्या सेवेपुरता मर्यादित करा: सेवा-विशिष्ट कॉन्फिगरेशन फाइल किंवा समर्पित OpenSSL कॉन्फिगरेशनचा प्रभाव जागतिक प्रोफाइलमधील निर्यातीपेक्षा लहान असतो।

अपवादासह चार गोष्टी लिहा: नेमकी सेटिंग, ती मंजूर करणारा मालक, प्रभावित क्लायंट, आणि तो काढला जाण्याची अट। निवृत्ती-अट नसलेला अपवाद तात्पुरत्या समर्थनासह जोडलेली कायमची कमकुवतता आहे।

रोलबॅक हे तुम्ही आधीच तपासलेले एकच पाऊल असावे। मागील कॉन्फिगरेशन ठेवा, बदल लागू करा, सेवा सुरू होते याची खात्री करा, आणि पुढील कनेक्शन अपेक्षेपेक्षा वेगळे वागल्यास कोणती फाइल पुनर्संचयित करायची ते नेमके जाणा।

नंतर ओळख आणि संरक्षण तपासा

यशस्वी कनेक्शन फक्त हे सिद्ध करते की सुधारित अटींनी त्याला स्वीकारले। होस्टनाव आणि सहकाऱ्याची तपासणी अजूनही त्यांचे काम करत आहे, वापरातील प्रमाणपत्र तुम्ही तैनात करू इच्छित होते तेच आहे, आणि वाटाघाटी केलेला डेटा चॅनेल तुम्ही मानत असलेल्या धोरणाशी जुळतो याची खात्री करा।

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

OpenSSL सुरक्षा पातळ्यांचा संदर्भ स्पष्ट सांगतो की फ्रेमवर्क किल्ल्या, स्वाक्षऱ्या, गट आणि संचांवर मर्यादा एकत्र लागू करते, आणि शून्य पातळी कॉलबॅक तपासते ते सर्व परवानगी देते। तुम्ही बदललेल्या गोष्टीचा व्याप्ती हाच आहे, आणि दुरुस्ती अरुंद होती का असे कोणी विचारल्यावर हेच वाक्य उद्धृत करायचे असते।

ऑडिट टिकून राहणारे हस्तांतरण सांगते की कोणत्या धोरणाने कोणते इनपुट नाकारले, काय बदलले, आणि त्यामुळे काय स्वीकारार्ह राहते। „ते SECLEVEL=0 सह काम करते“ हे एका कनेक्शनबद्दलचे निरीक्षण आहे, तैनातीचे सुरक्षा मूल्यांकन नाही।