शीर्ष PostgreSQL सुरक्षा खतरे

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

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

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

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

काश, हमें सुरक्षा मानसिकता के साथ काम करना पड़ता। इस मानसिकता के बिना, हम अपने सिस्टम को इस प्रकार के हमलों के प्रति संवेदनशील बना देते हैं। PostgreSQL अन्य प्रकार के सॉफ़्टवेयर की तरह ही समझौता, दुरुपयोग, चोरी, अनधिकृत पहुंच/नियंत्रण के लिए अतिसंवेदनशील है।

तो हम अपने PostgreSQL इंस्टालेशन के जोखिमों की संख्या को कम करने के लिए क्या उपाय कर सकते हैं?

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

मैंने हाल ही में PostgreSQL पर्यावरण को लक्षित करते हुए ज्ञात सुरक्षा 'चिंताओं' और 'खतरों' की खोज की। मेरी खोज में 2018 की पहली तिमाही के भीतर हाल की रिपोर्ट, लेख और ब्लॉग पोस्ट शामिल हैं। उस विशिष्ट समय सीमा के अलावा, मैंने लंबे समय से चली आ रही उन प्रसिद्ध चिंताओं का पता लगाया जो आज भी व्यवहार्य खतरे हैं (अर्थात् SQL इंजेक्शन), जबकि पॉलिश नहीं किया गया है। या 'हाल ही में खोजा गया . के रूप में ब्रांडेड '।

फ़ोटो का अवसर

डेटाबेस हमलों में एक गहरा गोता [भाग III]:क्यों स्कारलेट जोहानसन की तस्वीर ने मोनरो खनन शुरू करने के लिए मेरा पोस्टग्रेज डेटाबेस प्राप्त किया

इस चालाक मैलवेयर हमले के शब्द ने मेरे उद्देश्य खोज परिणामों में से सबसे अधिक 'हिट' लौटाए।

हम कई बेहतरीन ब्लॉग पोस्टों में से एक पर जाएंगे और इसकी सामग्री के बारे में विस्तार से जानकारी देंगे। मैंने इस खंड के अंत में अतिरिक्त ब्लॉग पोस्ट भी शामिल किए हैं, इसलिए सुनिश्चित हो जाएं और इस घुसपैठ का विवरण देने वाले उन पर भी जाएं।

अवलोकन

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

पेलोड को lo_export फ़ंक्शन के साथ रनटाइम पर डिस्क पर डंप किया जाता है। लेकिन जाहिरा तौर पर, ऐसा इसलिए होता है क्योंकि lo_export pg_proc बनाम सामान्य रूप से प्रत्यक्ष कॉलिंग (lo_export) में एक प्रविष्टि है।

अत्यधिक स्पष्टता के लिए सीधे ब्लॉग पोस्ट से दिलचस्प विवरण (उद्धृत लेख देखें),

अब हमलावर एक साधारण फ़ंक्शन - fun6440002537 का उपयोग करके स्थानीय सिस्टम कमांड निष्पादित करने में सक्षम है। यह SQL फ़ंक्शन C-भाषा फ़ंक्शन, "sys_eval", "tmp406001440" (sqlmapproject पर आधारित एक बाइनरी) में एक छोटा निर्यातित फ़ंक्शन को कॉल करने के लिए एक आवरण है, जो मूल रूप से SQL क्लाइंट से शेल कमांड को लागू करने के लिए प्रॉक्सी के रूप में कार्य करता है।

तो हमले के अगले चरण क्या होंगे? कुछ टोही। तो यह lshw -c वीडियो निष्पादित करके GPU का विवरण प्राप्त करने के साथ शुरू हुआ और CPU विवरण प्राप्त करने के लिए cat /proc/cpuinfo जारी रखा (आंकड़े 3-4)। हालांकि यह पहली बार में अजीब लगता है, यह पूरी तरह से समझ में आता है जब आपका अंतिम लक्ष्य आपकी अधिक पसंदीदा क्रिप्टोकरेंसी को माइन करना है, है ना?

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

(नोट:फोटो को उसके होस्ट किए गए स्थान से हटा दिया गया है। उल्लेख के लिए लिंकिंग लेख देखें।)

रिपोर्ट के मुताबिक पेलोड बाइनरी फॉर्मेट में है। उस बाइनरी कोड को फोटो में जोड़ा गया था ताकि अपलोड के दौरान एक वास्तविक फोटो को पास किया जा सके, जिससे एक देखने योग्य तस्वीर की अनुमति मिल सके।

डाउनलोड की गई फ़ाइल पर अनुमतियों के लिए wget, dd, और chmod निष्पादित करने के लिए जिम्मेदार SQL के लिए पोस्ट का चित्र 6 देखें। वह डाउनलोड की गई फ़ाइल फिर एक और निष्पादन योग्य बनाती है जो वास्तव में मोनरो के खनन के लिए जिम्मेदार है। बेशक, इस नापाक काम के बाद हाउसकीपिंग और सफाई की जरूरत है।

चित्र 7 में प्रदर्शन कर रहे SQL को दर्शाया गया है।

इम्पर्वा समापन खंड में संभावित उल्लंघन क्षेत्रों की इस सूची की निगरानी की सिफारिश करता है:

• pg_proc में प्रविष्टियों के माध्यम से lo_export या अप्रत्यक्ष कॉल पर सीधे PostgreSQL कॉल देखें।
• C-भाषा बायनेरिज़ को कॉल करने वाले PostgreSQL फ़ंक्शन से सावधान रहें।
• अपने डेटाबेस से इंटरनेट पर जावक नेटवर्क ट्रैफ़िक को ब्लॉक करने के लिए फ़ायरवॉल का उपयोग करें।
• सुनिश्चित करें कि आपका डेटाबेस सार्वजनिक आईपी पते के साथ असाइन नहीं किया गया है। यदि ऐसा है, तो केवल उन मेजबानों तक पहुंच प्रतिबंधित करें जो इसके साथ बातचीत करते हैं (एप्लिकेशन सर्वर या डीबीए के स्वामित्व वाले क्लाइंट)।

इम्पर्वा ने विभिन्न एंटीवायरस परीक्षणों के साथ-साथ यह भी विवरण दिया कि हमलावर संभावित रूप से कमजोर पोस्टग्रेएसक्यूएल सर्वरों का पता कैसे लगा सकते हैं। हालाँकि मैंने उन्हें यहाँ संक्षिप्तता के लिए शामिल नहीं किया, उनके निष्कर्षों के पूर्ण विवरण के लिए लेख देखें।

अनुशंसित पठन

• Imperva के 2 पूर्ववर्ती लेख हैं जो भाग 3 के साथ हैं (जिसकी चर्चा यहां की गई है)। जबकि वे पोस्टग्रेएसक्यूएल को भारी रूप से लक्षित नहीं करते हैं, जैसा कि हमने अभी-अभी देखा है, वे अत्यधिक जानकारीपूर्ण हैं:
  • भाग 1
  • भाग 2
• स्कारलेट जोहानसन पोस्टग्रेएसक्यूएल मैलवेयर हमला
• स्कारलेट जोहानसन छवि में छिपे कॉइनमिनर के साथ हैकर्स पोस्टग्रेएसक्यूएल डीबी को लक्षित करते हैं
• शोषण पर एक हैकर समाचार सूत्र।

सीवीई विवरण, रिपोर्ट और कमजोरियां

मैंने इस साइट का दौरा किया, जो प्रति विक्रेता के आधार पर नवीनतम सुरक्षा खतरों को पोस्ट करती है और 2018 की पहली तिमाही में 4 कमजोरियों की खोज की है। PostgreSQL सुरक्षा सूचना पृष्ठ ने भी उन्हें सूचीबद्ध किया है, इसलिए उस संसाधन से परामर्श करने के लिए स्वतंत्र महसूस करें।

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

वे प्रकाशित तिथि के क्रम में नीचे सूचीबद्ध हैं:

मैं. CVE-2018-1052 दिनांक प्रकाशित 2018-02-09 :अद्यतन दिनांक 3/10/2018

अवलोकन:

तालिका विभाजन में मेमोरी प्रकटीकरण भेद्यता 10.2 से पहले PostgreSQL 10.x में पाई गई थी, जिससे एक प्रमाणित हमलावर को एक विभाजित तालिका में उद्देश्य से तैयार की गई प्रविष्टि के माध्यम से सर्वर मेमोरी के मनमाने बाइट्स को पढ़ने की अनुमति मिलती है।

यह भेद्यता यहां पुष्टि की गई PostgreSQL 10.2 की रिहाई के साथ तय की गई थी। पुराने 9.x संस्करण का भी उल्लेख किया गया है, इसलिए अपने विशिष्ट संस्करण की जांच के लिए उस लिंक पर जाएं।

द्वितीय। CVE-2018-1053 प्रकाशित दिनांक 2018-02-09 :अद्यतन दिनांक 3/15/2018

अवलोकन:

PostgreSQL 9.3.x में 9.3.21 से पहले, 9.4.x 9.4.16 से पहले, 9.5.x 9.5.11 से पहले, 9.6.x 9.6.7 से पहले और 10.x 10.2 से पहले, pg_upgrad आउटपुट वाली वर्तमान कार्यशील निर्देशिका में फ़ाइल बनाता है umask के तहत `pg_dumpall -g` का, जो उस समय प्रभावी था जब उपयोगकर्ता ने pg_upgrad को लागू किया था, न कि 0077 से कम जो आमतौर पर अन्य अस्थायी फ़ाइलों के लिए उपयोग किया जाता है। यह एक प्रमाणित हमलावर को एक फ़ाइल को पढ़ने या संशोधित करने की अनुमति दे सकता है, जिसमें एन्क्रिप्टेड या अनएन्क्रिप्टेड डेटाबेस पासवर्ड हो सकते हैं। यदि कोई निर्देशिका मोड हमलावर को वर्तमान कार्यशील निर्देशिका की खोज करने से रोकता है या यदि प्रचलित umask हमलावर को फ़ाइल खोलने से रोकता है तो हमला संभव नहीं है।

पिछले CVE-2018-1052 की तरह, PostgreSQL 10.2 ने भेद्यता के इस हिस्से को ठीक किया:

सुनिश्चित करें कि "pg_upgrad" से बनी सभी अस्थायी फ़ाइलें गैर-विश्व-पठनीय हैं

PostgreSQL के कई पुराने संस्करण इस भेद्यता से प्रभावित हैं। सुनिश्चित करें और उन सभी सूचीबद्ध संस्करणों के लिए दिए गए लिंक पर जाएं।

III. CVE-2017-14798 दिनांक प्रकाशित 2018-03-01 :अद्यतन दिनांक 3/26/2018

अवलोकन:

PostgreSQL init स्क्रिप्ट में एक दौड़ की स्थिति का उपयोग हमलावर अपने विशेषाधिकारों को रूट तक बढ़ाने के लिए PostgreSQL खाते तक पहुंचने में सक्षम हैं।

हालांकि मुझे लिंकिंग पेज पर कहीं भी नहीं मिला कि PostgreSQL संस्करण 10 का उल्लेख किया गया था, कई पुराने संस्करण हैं, इसलिए पुराने संस्करणों को चलाने पर उस लिंक पर जाएं।

Suse Linux एंटरप्राइज़ सर्वर उपयोगकर्ता 2 लिंक किए गए लेखों में रुचि ले सकते हैं यहाँ और यहाँ जहाँ यह भेद्यता संस्करण 9.4 init स्क्रिप्ट के लिए तय की गई थी।

चतुर्थ। CVE-2018-1058 दिनांक प्रकाशित 2018-03-02 :अद्यतन दिनांक 3/22/2018

अवलोकन:

जिस तरह से PostgreSQL ने एक उपयोगकर्ता को अन्य उपयोगकर्ताओं के लिए एक क्वेरी के व्यवहार को संशोधित करने की अनुमति दी, उसमें एक दोष पाया गया। उपयोगकर्ता खाते वाला एक हमलावर डेटाबेस में सुपरयूज़र की अनुमति के साथ कोड निष्पादित करने के लिए इस दोष का उपयोग कर सकता है। संस्करण 9.3 से 10 प्रभावित हैं।

इस अद्यतन रिलीज़ में एक दिलचस्प लिंक किए गए दस्तावेज़ के साथ इस भेद्यता का उल्लेख है जिसे सभी उपयोगकर्ताओं को देखना चाहिए।

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

मैं संक्षेप में बताने की पूरी कोशिश करूंगा, लेकिन अपने फायदे, समझ और समझ के लिए गाइड पर जाऊं।

अवलोकन:

PostgreSQL संस्करण 7.3 के आगमन के साथ, स्कीमा को पारिस्थितिकी तंत्र में पेश किया गया था। यह एन्हांसमेंट उपयोगकर्ताओं को अलग-अलग नामस्थानों में ऑब्जेक्ट बनाने की अनुमति देता है। डिफ़ॉल्ट रूप से, जब कोई उपयोगकर्ता डेटाबेस बनाता है, तो PostgreSQL एक सार्वजनिक स्कीमा भी बनाता है जिसमें सभी नए ऑब्जेक्ट बनाए जाते हैं। जो उपयोगकर्ता किसी डेटाबेस से जुड़ सकते हैं, वे उस डेटाबेस में सार्वजनिक स्कीमा में ऑब्जेक्ट भी बना सकते हैं।

सीधे गाइड से यह अनुभाग अत्यधिक महत्वपूर्ण है (उद्धृत लेख देखें):

स्कीमा उपयोगकर्ताओं को वस्तुओं को नाम देने की अनुमति देती है, इसलिए एक ही नाम की वस्तुएं एक ही डेटाबेस में विभिन्न स्कीमाओं में मौजूद हो सकती हैं। यदि अलग-अलग स्कीमा में समान नाम वाले ऑब्जेक्ट हैं और विशिष्ट स्कीमा/ऑब्जेक्ट जोड़ी निर्दिष्ट नहीं है (यानी schema.object), PostgreSQL यह तय करता है कि search_path सेटिंग के आधार पर किस ऑब्जेक्ट का उपयोग करना है। search_path सेटिंग उस क्रम को निर्दिष्ट करती है जिस क्रम में किसी वस्तु की तलाश में स्कीमा खोजे जाते हैं। Search_path के लिए डिफ़ॉल्ट मान $user,public है जहां $user कनेक्टेड उपयोगकर्ता के नाम को संदर्भित करता है (जिसे SELECT SESSION_USER; निष्पादित करके निर्धारित किया जा सकता है)।

एक अन्य महत्वपूर्ण बिंदु यहाँ है:

CVE-2018-1058 में वर्णित समस्या डिफ़ॉल्ट "सार्वजनिक" स्कीमा के आसपास है और PostgreSQL कैसे search_path सेटिंग का उपयोग करता है। पोस्टग्रेएसक्यूएल स्कीमा के भीतर वस्तुओं की खोज कैसे करता है, इसके साथ संयुक्त रूप से अलग-अलग स्कीमा में समान नाम वाले ऑब्जेक्ट बनाने की क्षमता, उपयोगकर्ता के लिए अन्य उपयोगकर्ताओं के लिए क्वेरी के व्यवहार को संशोधित करने का अवसर प्रस्तुत करती है।

नीचे एक उच्च-स्तरीय सूची दी गई है, जो इस भेद्यता के जोखिम को कम करने के लिए निर्धारित इन प्रथाओं के आवेदन की सिफारिश करती है:

• उपयोगकर्ताओं को सार्वजनिक स्कीमा में नए ऑब्जेक्ट बनाने की अनुमति न दें
• डेटाबेस उपयोगकर्ताओं के लिए डिफ़ॉल्ट search_path सेट करें
• PostgreSQL कॉन्फ़िगरेशन फ़ाइल (postgresql.conf) में डिफ़ॉल्ट search_path सेट करें

एसक्यूएल इंजेक्शन

कोई भी 'सुरक्षा-थीम वाला SQL ब्लॉग पोस्ट या आलेख SQL इंजेक्शन का उल्लेख किए बिना स्वयं को इस तरह लेबल नहीं कर सकता है। हालांकि हमले का यह तरीका किसी भी तरह की कल्पना नहीं है 'ब्लॉक पर नया बच्चा ', इसे शामिल करना होगा।

SQL इंजेक्शन हमेशा एक खतरा होता है और शायद वेब एप्लिकेशन स्पेस में इससे भी ज्यादा। कोई भी SQL डेटाबेस - PostgreSQL सहित- इसके लिए संभावित रूप से असुरक्षित है।

जबकि मेरे पास SQL ​​इंजेक्शन पर गहन ज्ञान का आधार नहीं है - जिसे SQLi के रूप में भी जाना जाता है- मैं एक संक्षिप्त सारांश प्रदान करने की पूरी कोशिश करूंगा, यह आपके PostgreSQL सर्वर को संभावित रूप से कैसे प्रभावित कर सकता है, और अंततः शिकार गिरने के जोखिम को कैसे कम कर सकता है इसके लिए।

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

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

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

यहाँ OWASP SQL इंजेक्शन प्रिवेंशन चीट शीट से SQL इंजेक्शन के जोखिम को कम करने के लिए उल्लेखनीय सुझाव दिए गए हैं। सुनिश्चित करें और अभ्यास में उपयोग के पूर्ण विवरण के लिए इसे देखें (उद्धृत लेख देखें)।

प्राथमिक सुरक्षा:

• विकल्प 1:तैयार वक्तव्यों का उपयोग (पैरामीटरयुक्त प्रश्नों के साथ)
• विकल्प 2:संग्रहित प्रक्रियाओं का उपयोग
• विकल्प 3:श्वेत सूची इनपुट सत्यापन
• विकल्प 4:उपयोगकर्ता द्वारा प्रदत्त सभी इनपुट से बचना

अतिरिक्त सुरक्षा:

• इसके अलावा:कम से कम विशेषाधिकार लागू करना
• इसके अलावा:एक माध्यमिक रक्षा के रूप में श्वेत सूची इनपुट सत्यापन करना

अनुशंसित पठन:

मैंने आगे के अध्ययन और जागरूकता के लिए जानकारी के भार के साथ अतिरिक्त लेख शामिल किए हैं:

• एसक्यूएल इंजेक्शन क्या है? यह पुराना लेकिन गुडी आपके वेब एप्लिकेशन को नुकसान पहुंचा सकता है
• एसक्यूएल इंजेक्शन (विकिपीडिया)
• एसक्यूएल इंजेक्शन (क्लाउडफ्लेयर)
• एसक्यूएल इंजेक्शन (w3schools.com)
• एसक्यूएल इंजेक्शन प्रिवेंशन चीट शीट
• एसक्यूएल इंजेक्शन के लिए परीक्षण
• एसक्यूएल इंजेक्शन भेद्यताएं और उन्हें कैसे रोकें
• एसक्यूएल इंजेक्शन चीट शीट

भूमिका के विशेषाधिकार पोस्ट करता है

हमारे पास कुछ के लिए एक कहावत है "हम अपने सबसे बड़े दुश्मन हैं ।"

हम निश्चित रूप से इसे PostgreSQL वातावरण में काम करने के लिए लागू कर सकते हैं। उपेक्षा, गलतफहमी, या परिश्रम की कमी हमलों और अनधिकृत उपयोग के लिए उतने ही अवसर हैं जितने कि जानबूझकर शुरू किए गए।

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

मैं एक ऐसे क्षेत्र का उल्लेख करूंगा जिसे समय-समय पर हमेशा पुनर्मूल्यांकन या पुनर्मूल्यांकन की आवश्यकता होती है।

अनुचित या बाहरी भूमिका विशेषाधिकार।

• सुपरयूजर
• क्रिएटरोल
• क्रिएटडीबी
• अनुदान

विशेषाधिकारों का यह समामेलन निश्चित रूप से देखने लायक है। SUPERUSER और CREATROLE बेहद शक्तिशाली कमांड हैं और एक डीबीए के हाथों में बेहतर सेवा दी जाएगी जैसा कि एक विश्लेषक या डेवलपर के विपरीत आपको नहीं लगता?

क्या भूमिका को वास्तव में CREATEDB विशेषता की आवश्यकता है? अनुदान के बारे में क्या? उस विशेषता के गलत हाथों में दुरुपयोग की संभावना है।

अपने परिवेश में इन विशेषताओं को भूमिकाओं की अनुमति देने से पहले सभी विकल्पों पर भारी ध्यान दें।

रणनीतियां, सर्वोत्तम प्रक्रियाएं, और सख्त करना

नीचे उपयोगी ब्लॉग पोस्ट, लेख, चेकलिस्ट और गाइड की एक सूची है जो खोज परिणामों के 'वर्ष पहले' (इस लेखन के समय) के लिए लौटे थे। वे महत्व के किसी भी क्रम में सूचीबद्ध नहीं हैं और प्रत्येक उल्लेखनीय सुझाव देते हैं।

• अपने पोस्टग्रेज सर्वर को संभावित अटैक वेक्टर से बचाने के आसान तरीके:स्कारलेट जोहानसन की एक दुष्ट तस्वीर
• आपके PostgreSQL डेटाबेस को सुरक्षित करने में मदद करना
• कठिनाई न करें... सुरक्षा सुनिश्चित करने के लिए अपने PostgreSQL डेटाबेस को सख्त करें
• अपने PostgreSQL डेटाबेस को कैसे सुरक्षित करें - 10 टिप्स
• पोस्टग्रेएसक्यूएल को बाहरी हमले से सुरक्षित करना
• PostgreSQL विशेषाधिकार और सुरक्षा - सार्वजनिक योजना को बंद करना

निष्कर्ष

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

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

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

आपको अपने PostgreSQL डेटाबेस इंस्टेंस को सुरक्षित करने के बारे में अधिक सामग्री के लिए, सलाह के लिए Manynines ब्लॉग की ओर मुड़ें:PostgreSQL के लिए सुरक्षा ऑडिट को स्वचालित करना सीखना निश्चित रूप से सही दिशा में एक कदम होगा। ट्विटर, लिंक्डइन पर हमें फॉलो करना सुनिश्चित करें, और अधिक अपडेट के लिए हमारे आरएसएस फ़ीड की सदस्यता लें, और हम आपको अगले एक में देखेंगे।