OpenVPN मध्ये RAND_bytes अयशस्वी: लायब्ररी त्रुटी किंवा गहाळ नोड

RAND_bytes() failed एका स्थानिक आदिमाबद्दलचे विधान आहे, खाते, पूर्व-सामायिक की किंवा दूरस्थ पोर्टबद्दल नाही। दोन अतिशय वेगळ्या बिघाड्या तीच ओळ निर्माण करतात आणि वेगळे पुरावे सोडतात। एक क्रिप्टोग्राफिक बॅकएंड आहे जो बाइट्स देण्यास नकार देतो; दुसरी अशी प्रक्रिया आहे जी ज्या एन्ट्रॉपी स्रोतासाठी तिचा कोड बांधला गेला तिथपर्यंत पोहोचत नाही। त्या वेगळ्या करण्यासाठी त्रुटींच्या रांगेचे एक वाचन आणि जेलमधील प्रक्रियेच्या फाइल सिस्टम दृश्याकडे एक नजर लागते, आणि ही तपासणी /dev खाली काहीही तयार होण्यापूर्वी असायला हवी।

परतावा मूल्य काय वेगळे करते

दस्तऐवजीकृत करार तीन निष्कर्ष वेगळे करतो, दोन नाही: यशासाठी 1, लोड केलेली RAND पद्धत विनंतीला समर्थन देत नाही तेव्हा -1, आणि इतर बिघाडींसाठी 0, स्पष्टीकरण त्रुटींच्या रांगेत राहते। RAND_bytes संदर्भ एक मुद्दा जोडतो जो दुर्लक्षित करणे सोपे आहे: डीफॉल्ट जनरेटर समर्थित प्लॅटफॉर्मवर ऑपरेटिंग सिस्टमकडून बीज घेतो, आणि हे बीजारोपण अयशस्वी झाल्यास तो अंदाज करण्यायोग्य बाइट्स परत देण्याऐवजी त्रुटी स्थितीत राहतो।

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

जेव्हा लपलेला उपकरण नोड खरा कारण असतो

मर्यादित सेवा तुम्ही टाइप करत असलेल्या शेलपेक्षा वेगळे झाड पाहते। chroot जेल, कंटेनर प्रतिमा आणि कठोर केलेल्या unit फाइल्स नियमितपणे असे /dev सादर करतात ज्यात यजमानापेक्षा कमी नोड असतात। अयशस्वी अंमलबजावणी /dev/urandom मार्ग नावाने उघडत असेल, तर यजमान स्वतः पूर्णपणे निरोगी दिसत असताना हा फरक सुरुवात तोडण्यासाठी पुरतो। जेलबाहेर अस्तित्वात असलेले उपकरण जेलमधील प्रक्रियेला काय उघडण्याची परवानगी आहे याबद्दल काहीही सिद्ध करत नाही।

तथापि प्रत्येक यादृच्छिक इंटरफेसला मार्गाची गरज नसते। लिनक्समधील getrandom सिस्टम कॉल फाइल नाव किंवा फाइल डिस्क्रिप्टर स्वीकारत नाही, आणि तिचे मॅन्युअल पान नमूद करते की हा गुणधर्म नेमका तिथे उपयुक्त आहे जिथे chroot उपकरण मार्ग लपवते।

म्हणून गहाळ नोडचे स्पष्टीकरण कोडच्या एका शाखेबद्दलचे गृहीतक आहे, यादृच्छिक संख्यांबद्दलचा सर्वसाधारण नियम नाही। पुरावे मार्गाचे नाव घेतात तेव्हा ते टिकते, आणि पुरावे दुसरे काही नाव घेतात तेव्हा ते अंदाज आहे।

प्रथम त्रुटींची रांग वाचा, नंतर प्रक्रियेचे दृश्य

प्रश्न निकाली काढण्याचा सर्वात वेगवान मार्ग म्हणजे लायब्ररीने आधीच नोंदवलेले वाचणे, आणि नंतर थेट जेलमधील दृश्याकडे पाहणे। सेवेने प्रत्यक्षात लोड केलेल्या OpenSSL बिल्डपासून सुरुवात करा, कारण पुरवठादार स्टॅक प्रमुख आवृत्त्या आणि वितरणांमध्ये भिन्न असतात। नंतर systemdला विचारा कोणती प्रक्रिया चालू आहे आणि तिला कोणते निर्बंध लागू आहेत। दोन्ही तथ्ये टेबलावर आल्यावरच ती प्रक्रिया जे नोड पाहू शकते त्यांची यादी करणे फायद्याचे ठरते।

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

हे वाचन त्या प्रक्रियेवर करा, योगायोगाने उघड्या असलेल्या शेलवर नाही। यजमानाच्या /dev ची तुलना असंबंधित प्रक्रियेच्या दृश्याशी करणे हाच तो मार्ग आहे ज्याने चुकीचे अवलंबन दोनदा दुरुस्त होते।

अवलंबन फक्त तेव्हाच जोडा जेव्हा तुम्ही त्याचे नाव देऊ शकता

पुरावे खरोखर मार्गाचे नाव घेतात तेव्हा दुरुस्ती लहान असते: तोच एक मार्ग जेलमध्ये उपलब्ध करा आणि बाकी सर्व सोडून द्या। एका नोडचे bind mount सहसा पुरते, आणि mknod नोडच्या मानक major आणि minor क्रमांकांसह ज्या इन्स्टॉलेशनवर mount पर्याय नाही तिथे तोच निकाल देतो। सँडबॉक्सचा विस्तार, प्रत्येक वर्ण उपकरणाला प्रवेश देणे किंवा PrivateDevices बंद करणे हे लक्ष्यित दुरुस्तीऐवजी कायमचा सुरक्षा घट आणते।

एन्ट्रॉपी डेमॉन त्या दुरुस्तीचा पर्याय नाही। haveged सारखी पॅकेजेस कर्नेल पूल कसा पोषला जातो ते बदलतात; ते जेलमधील प्रक्रियेला उघडण्यास परवानगी असलेला मार्ग तयार करू शकत नाहीत। त्यापैकी एक स्थापित केल्याने आरोग्य आलेख चांगला दिसू शकतो, तर उघडण्याचा कॉल अजूनही अयशस्वी होतो। दोन्ही समस्या वेगळ्या ठेवा, अन्यथा पुढील बिघाड पुन्हा चुकीच्या थरावर ढकलला जाईल।

जनरेटर आणि बोगदा स्वतंत्रपणे तपासा

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

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

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