एक उदाहरण के रूप में LoRaWAN का उपयोग कर वायरलेस प्रोटोकॉल सुरक्षित करना

हाय, हैब्र।

मैं एक बार फिर बात करना चाहूंगा कि IoT उपकरणों में उपयोग किए जाने वाले वायरलेस नेटवर्क में डेटा सुरक्षा के बुनियादी (पढ़ें: न्यूनतम आवश्यक) स्तर को कैसे प्रदान किया जाता है, उदाहरण के लिए LoRaWAN का उपयोग करके।

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


LoRaWAN संदेश सर्वर और डिवाइस के बीच

यद्यपि चित्र में लोरावन में संदेश योजना बहुत सरल दिखती है - यह सरलता भ्रामक है: इसमें बहुत सारे काम करने हैं, और इसमें एक भी पिक्सेल शानदार नहीं है। अब आप समझेंगे क्यों।

हम एक उदाहरण के रूप में LoRaWAN 1.0.2 का उपयोग करके विश्लेषण करेंगे और संभावित खतरों से नृत्य करेंगे - एक अच्छे डेवलपर के लिए हमेशा यह सोचना चाहिए कि उसकी प्रणाली कैसे सुरक्षित है, लेकिन इसके बारे में कैसे तोड़ा जा सकता है। अन्यथा, कोई और उसके लिए इसके बारे में सोचेगा।

तो, वायरलेस नेटवर्क में मुख्य खतरे क्या हैं - और उनसे खुद को कैसे बचाएं?

उपयोगकर्ता डेटा का अवरोधन

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

इससे बचाव का सबसे आसान तरीका डेटा एन्क्रिप्शन है।

लोरावन में, उपयोगकर्ता डेटा को क्रमशः एईएस -128 एल्गोरिथ्म का उपयोग करके 128 बिट्स (16 बाइट्स) की कुंजी लंबाई के साथ एन्क्रिप्ट किया गया है। एईएस एक विश्वसनीय एल्गोरिथ्म है, हालांकि, कम से कम आधुनिक माइक्रोकंट्रोलर्स पर, जिसमें एक हार्डवेयर एन्क्रिप्शन ब्लॉक भी नहीं है, इसका उपयोग महत्वपूर्ण ओवरहेड नहीं करता है: एक कॉर्टेक्स-एम 3 पर 48 मेगाहर्ट्ज की आवृत्ति के साथ, एक 16-बाय ब्लॉक को खरोंच से लगभग 100 μs में एन्क्रिप्ट किया गया है।

डेटा रिपीट

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

लोरावन में, प्रत्येक पैकेट में एक काउंटर जोड़ा जाता है । यदि पैकेट नेटवर्क सर्वर पर एक काउंटर के बराबर या पिछले एक से कम के साथ आता है, तो यह पैकेट बस छोड़ दिया जाता है। प्रति मीटर दो बाइट्स और संदेश ट्रांसमिशन की एक विशिष्ट IoT- सिस्टम गति के साथ, यह बहुत लंबे समय तक चलेगा - उदाहरण के लिए, यहां तक ​​कि एक घरेलू मौसम स्टेशन जो हर मिनट तापमान प्रसारित करता है, एक महीने के बाद ही इसे ओवरफ्लो कर देगा (LoRWWAN 4-बाइट काउंटर की अनुमति देता है)।

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

यह दो तरीकों में से एक है:

• इस तरह का पैकेज भेजने से पहले, डिवाइस को नेटवर्क पर पंजीकरण प्रक्रिया से गुजरना होगा (लोरावन नेटवर्क में, इस प्रक्रिया को पास कहा जाता है)
• सर्वर नंबर 0 के साथ अगले पैकेट के आगमन की अनुमति देता है, जबकि उलटी गिनती शुरू होती है

LoRaWAN में दोनों योजनाओं का उपयोग इस आधार पर किया जाता है कि उपकरण कैसे सक्रिय होता है - OTAA या ABP (हम नीचे उनके बारे में बात करेंगे)। पहला विकल्प ओटीएए के लिए उपयोग किया जाता है, और डिवाइस को नई एन्क्रिप्शन कुंजी भी दी जाती है - इसलिए यहां तक ​​कि एक हमलावर जिसने आपके मौसम स्टेशन के तहत डेढ़ महीने बिताए हैं, वह किसी भी पहले से दर्ज किए गए पैकेट को प्रसारित करने में सक्षम नहीं होगा, ताकि सिस्टम इसे स्वीकार कर सके।

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

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

नकली काउंटर

हालांकि, सवाल तुरंत उठता है - क्या होगा यदि काउंटर नकली है? आप इसे पैकेट के एन्क्रिप्टेड हिस्से में रख सकते हैं, लेकिन तब उपयोगकर्ता डेटा की वास्तविक मात्रा में दो बाइट्स की कमी होगी। आप न केवल उपयोगकर्ता डेटा को एन्क्रिप्ट कर सकते हैं, लेकिन फिर, सबसे पहले, आपको 16-बाइट ब्लॉक आकार के अनुकूल होना होगा, और दूसरी बात, नेटवर्क सर्वर पर लोड बढ़ जाएगा, जिसे पैकेज पर किसी भी कार्रवाई के लिए पहले डिक्रिप्ट करना होगा (योजना में, जब केवल उपयोगकर्ता डेटा एन्क्रिप्ट किया गया है, यदि पैकेज को औपचारिक रूप से अनदेखा किया जाता है, तो कुछ भी डिक्रिप्ट करने की आवश्यकता नहीं है)।

यह स्पष्ट है कि यह हमारे लिए कोई फर्क नहीं पड़ता कि हमलावर पैकेज नंबर जानता है या नहीं - इस योजना में नेटवर्क फिर से पंजीकरण (ओटीएए) के साथ यह ज्ञान उसे बिल्कुल भी मदद नहीं करेगा, और एबीपी में वह मौसम के लिए समुद्र द्वारा बहुत लंबे समय तक प्रतीक्षा करेगा, अर्थात्। नंबर N-1 के साथ पैकेट का अगला आगमन।

इसलिए, यह काफी है कि उसे इस नंबर को बदलने न दें।

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

यही है, अगले पैकेज को स्वीकार करने के बाद, हम जल्दी से इसके काउंटर (प्रेषक पता, आदि) में देख सकते हैं, और यदि यह हमारा है और सही है, तो पहले से ही हस्ताक्षर को सत्यापित करें (इस पर अतिरिक्त संसाधन खर्च कर रहे हैं), और अगर हस्ताक्षर भी सही है - डेटा को डीक्रिप्ट करें और संचारित करें उन्हें आगे।

अपरिवर्तित डेटा पर नज़र रखना

हमारे लिए दुर्भाग्य से, किसी हमलावर को डेटा को समझने से रोकने या कम से कम इसे दोहराने के लिए पर्याप्त नहीं है - कुछ मामलों में यह उसके लिए यह समझने के लिए पर्याप्त होगा कि वे बदल नहीं रहे हैं। एक पाठ्यपुस्तक का उदाहरण घर के पानी के मीटर हैं: यदि आप केवल यह जानना चाहते हैं कि क्या मालिक घर पर हैं, तो यह आपके लिए बिल्कुल मायने नहीं रखता है कि कितने लीटर हैं, यह जानना आपके लिए महत्वपूर्ण है कि क्या यह मूल्य बढ़ रहा है ।

जाहिर है, डेटा एन्क्रिप्शन एक प्रतिवर्ती प्रक्रिया है (उन्हें डिक्रिप्ट किया जा सकता है), जिसका अर्थ है कि समान कुंजी के साथ एन्क्रिप्ट किया गया समान डेटा हमेशा समान दिखता है। पानी के मीटर से पैकेट प्राप्त करते समय, जिसकी रीडिंग नहीं बदलती है, आप पैकेट को डिक्रिप्ट किए बिना समझ सकते हैं कि वे नहीं बदलते हैं।

इससे निपटने के लिए काफी सरल है - या तो डेटा या कुंजी को बदलना होगा। डेटा को बदलने के लिए, आप उन्हें नमक जोड़ सकते हैं - कुछ यादृच्छिक बाइट्स जो डिक्रिप्शन के बाद बस फेंक दिए जाते हैं। दुर्भाग्य से, एक पैकेट के 16 बाइट पहले से ही विरल हैं, इसलिए सामान्य स्थिति में हम उनमें से 2-4 बाइट्स वास्तविक कचरे पर खर्च नहीं करना चाहते हैं।

लोरावन एक चालबाज योजना का उपयोग करता है । याद रखें हमारे पास एक पैकेट काउंटर है? तो, यह विशेष रूप से काउंटर प्लस डिवाइस और पैकेट के बारे में जानकारी (LoRaWAN नेटवर्क पर डिवाइस का संक्षिप्त पता, डेटा ट्रांसफर दिशा, 16-बाइट काउंटर) एईएस एल्गोरिथ्म का उपयोग करके एन्क्रिप्ट किया गया है, और XOR परिणाम उपयोगकर्ता पैकेट के साथ है।

नतीजतन, पेलोड बाइट्स बर्बाद नहीं होते हैं, और प्रत्येक संदेश अलग-अलग दिखता है चाहे लोड बदल गया हो या नहीं।

PS एक और विकल्प है, थोड़ा सरल: संदेश काउंटर को कुंजी के अंतिम एन बाइट्स के रूप में उपयोग करें। इस मामले में, कुंजी हर बार नई होगी, लेकिन क्योंकि चूंकि सर्वर को संदेश काउंटर का मूल्य पता है (यह संदेश के अनएन्क्रिप्टेड हिस्से में है), यह इसे पुनर्स्थापित करने में सक्षम होगा। माइनस - यदि आपके पैकेज में कई 16-बाइट ब्लॉक हैं, और उनके पास समान डेटा है, तो एन्क्रिप्शन के बाद वे समान रहेंगे।

हमलावर ने एन्क्रिप्शन कुंजी सीख ली है

यह एक बहुत ही वास्तविक स्थिति है - IoT को बड़ी संख्या में उपकरणों के उपयोग की विशेषता है, जिस पर आपके पास बाहरी लोगों तक पहुंच पर पर्याप्त विश्वसनीय नियंत्रण नहीं हो सकता है (और यदि आप एक नेटवर्क ऑपरेटर हैं, तो आपके ग्राहक परिभाषा के अनुसार, बाहरी लोग हैं)।

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

लोरावन चाबियों का उपयोग करने के लिए दो योजनाओं को लागू करता है, प्रत्येक डिवाइस के लिए व्यक्तिगत:

• ओवर द एयर एक्टिवेशन, ओटीएए - कुंजियाँ नेटवर्क सर्वर द्वारा उत्पन्न होती हैं, जब भी कोई उपकरण इसमें पंजीकृत होता है
• निजीकरण द्वारा सक्रियण - कुंजी निर्माता द्वारा निर्धारित की जाती है और डिवाइस पर संग्रहीत होती है, कभी नहीं बदलती है

कुल में कम से कम दो कुंजियाँ हैं - AppSKey, जो उपयोगकर्ता डेटा को एन्क्रिप्ट करती है, और NwkSKey, जो संदेश पर हस्ताक्षर करता है।

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

हालांकि, ओटीएए में चाबियाँ प्राप्त करने की प्रक्रिया एक अलग कहानी है, जिसे अगर गलत तरीके से लागू किया जाता है, तो कई और प्रकार के हमलों को जन्म दे सकता है।

उत्पन्न कुंजियों का अवरोधन

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

इसलिए , लोरावन उपकरणों में एक तीसरी कुंजी होती है - ऐपकेई, डिवाइस में कसकर वायर्ड हो जाती है और एक ही पल में उपयोग की जाती है: नेटवर्क पर पंजीकरण करते समय। इसके साथ, डिवाइस और सर्वर के बीच सत्र कुंजियों का आदान-प्रदान होता है।

आदर्श रूप से, AppKey प्रत्येक डिवाइस के लिए अद्वितीय होना चाहिए, लेकिन कई मामलों में समान AppKey के उपयोग की अनुमति है - चूंकि इसे केवल एक बार की आवश्यकता होती है, इसे मान्य माना जा सकता है।

डिवाइस से कनेक्ट होने से पहले AppKey नेटवर्क सर्वर पर अपनी सेटिंग्स में दर्ज किया गया है।

तो, डिवाइस एक पंजीकरण अनुरोध (JoinRequest) उत्पन्न करता है, इसे एन्क्रिप्ट नहीं कर रहा है (इसमें कोई संवेदनशील जानकारी नहीं है), लेकिन AppKey कुंजी के साथ इसे हस्ताक्षर करना। नेटवर्क सर्वर, इस पैकेट को प्राप्त कर रहा है और प्रेषक का पता (चाहे यह हमारा उपकरण है) की जांच कर रहा है और फिर हस्ताक्षर, JoinAccept पैकेट के साथ प्रतिक्रिया करता है, जिसमें यह नेटवर्क सेटिंग्स को स्थानांतरित करता है - ठीक है, यह वास्तव में पंजीकरण की पुष्टि करता है।

AppSKey और NwkSKey कुंजियाँ कहाँ से आती हैं?

यह प्रतिक्रिया में सर्वर द्वारा भेजे गए एक यादृच्छिक AppNonce नंबर, कुंजी नंबर (1 या 2), नेटवर्क आईडी और एक अन्य यादृच्छिक DevNonce नंबर के संयोजन के AppKey कुंजी के साथ एईएस -128 एन्क्रिप्शन का परिणाम है:

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce) 

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

स्वयं पर एक डेटा स्ट्रीम का अवरोधन

लेकिन यह सब नहीं है!

हां, नेटवर्क पर पंजीकरण की घटना आमतौर पर एक असीम चीज है, लेकिन कल्पना करें कि एक हमलावर इसे शुरू करने और अवरोधन करने में सक्षम था।

फिर, यदि वह सिर्फ JoinRequest पैकेट भेजता है, जिसे उसने रिकॉर्ड किया है, तो उसमें कुछ भी बदले बिना, सर्वर JoinAccept पैकेट के साथ प्रतिक्रिया देगा, नई कुंजी उत्पन्न करेगा। इसके बाद, हमला किया गया डिवाइस बस सर्वर के साथ संचार करना बंद कर देता है, क्योंकि यह JoinRequest को आरंभ नहीं करता है और कुंजी को अपडेट करने का कोई कारण नहीं देखता है। यही है, एक ही हमले को दोहराया जाता है - लेकिन पहले से ही नेटवर्क पर पंजीकरण प्रक्रिया पर।

एक हमलावर डेटा को नकली नहीं कर पाएगा, क्योंकि इसके लिए आपको चाबियाँ जानने की जरूरत है, और उन्हें प्राप्त करने के लिए आपको ऐपके को जानना होगा, जिसे वह नहीं जानता है। लेकिन डिवाइस को नेटवर्क से बाहर खटखटाने के लिए - वह कर सकता है।

इससे बचने के लिए, पंजीकरण के दौरान, डिवाइस सर्वर को एक यादृच्छिक संख्या DevNonce भेजता है (देखो, यह ऊपर के पैकेजों में है)। इस तथ्य के अलावा कि चाबियाँ इसके आधार पर उत्पन्न होती हैं, यह एक और उद्देश्य से काम करती है - लोरावन सर्वर देवनोनेस संग्रह संग्रहीत करता है । यदि डिवाइस को पहले से उपयोग किए गए DevNonce के साथ दोहराया पंजीकरण अनुरोध प्राप्त होता है, तो सर्वर बस इसे अनदेखा करेगा।

बदले में, डिवाइस प्रत्येक पंजीकरण पर एक नया DevNonce उत्पन्न करने के लिए बाध्य है (यानी, पारंपरिक पैकेट के रिले के साथ सर्किट - "एक प्रतिक्रिया प्राप्त नहीं हुई, दूसरी बार रेडियो में एक ही पैकेट को बाहर थूकना" - यहाँ काम नहीं करता है, JoinRequest हर बार फिर से बनाया जाता है)।

निष्कर्ष

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

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

और यदि आप IoT के लिए अपना स्वयं का प्रोटोकॉल डिजाइन कर रहे हैं, तो सुव्यवस्थित LoRaWAN, जो हमलों के बुनियादी तरीकों की समझ के साथ संयुक्त है, यह सीखने का एक शानदार अवसर प्रदान करता है कि इस सुरक्षा को ठीक से कैसे व्यवस्थित किया जाए।