MySQL/MariaDB सर्वर को कैसे सुरक्षित करें

MongoDB डेटाबेस पर हमलों के बाद, हमने हाल ही में यह भी देखा है कि MySQL सर्वरों को रैंसमवेयर द्वारा लक्षित किया जा रहा है। सार्वजनिक और निजी बादलों की बढ़ती स्वीकार्यता को देखते हुए यह आश्चर्य की बात नहीं है। क्लाउड में खराब तरीके से कॉन्फ़िगर किया गया डेटाबेस चलाना एक प्रमुख दायित्व बन सकता है।

इस ब्लॉग पोस्ट में, हम आपके साथ अपने MySQL या MariaDB सर्वर की सुरक्षा और सुरक्षा के बारे में कई टिप्स साझा करेंगे।

अटैक वेक्टर को समझना

SCMagazine का हवाला देते हुए:
“हमले की शुरुआत MySQL डेटाबेस के लिए रूट पासवर्ड को जबरदस्ती करने से होती है। एक बार लॉग इन करने के बाद, MySQL डेटाबेस और टेबल लाए जाते हैं। फिर हमलावर 'चेतावनी' नामक एक नई तालिका बनाता है जिसमें एक संपर्क ईमेल पता, एक बिटकॉइन पता और भुगतान की मांग शामिल होती है। "

लेख के आधार पर, हमला वेक्टर ब्रूट-फोर्स विधि के माध्यम से MySQL रूट पासवर्ड का अनुमान लगाकर शुरू होता है। ब्रूट-फोर्स अटैक में एक हमलावर होता है जो अंततः सही ढंग से अनुमान लगाने की आशा के साथ कई पासवर्ड या पासफ़्रेज़ की कोशिश करता है। इसका मतलब है कि छोटे पासवर्ड आमतौर पर बहुत जल्दी खोजे जा सकते हैं, लेकिन लंबे पासवर्ड में दिन या महीने लग सकते हैं।

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

अपनी पासवर्ड नीति की समीक्षा करें

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

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

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

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

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

उपयोगकर्ता नीति की समीक्षा करें

कुछ उपयोगकर्ताओं को महत्वपूर्ण प्रशासन अधिकार, विशेष रूप से अनुदान, सुपर और प्रक्रिया रखने के लिए सीमित करें। आप super_read_only को भी सक्षम कर सकते हैं यदि सर्वर एक गुलाम है, केवल MySQL 5.7.8 और Percona सर्वर 5.6.21 और बाद में उपलब्ध है (दुख की बात है कि MariaDB के साथ नहीं)। सक्षम होने पर, सर्वर किसी भी अद्यतन की अनुमति नहीं देगा, प्रतिकृति रिपॉजिटरी को अद्यतन करने के अलावा, यदि दास स्थिति लॉग टेबल हैं, यहां तक ​​​​कि उन उपयोगकर्ताओं के लिए भी जिनके पास सुपर विशेषाधिकार है। प्रवेश के दायरे को कम करने के लिए डिफ़ॉल्ट परीक्षण डेटाबेस और खाली पासवर्ड वाले किसी भी उपयोगकर्ता को हटा दें। यह एक डेटाबेस सलाहकार के रूप में कार्यान्वित ClusterControl द्वारा की गई सुरक्षा जाँचों में से एक है।

एकल खाते में अनुमत कनेक्शनों की संख्या को सीमित करना भी एक अच्छा विचार है। आप mysqld में max_user_connections चर सेट करके ऐसा कर सकते हैं (डिफ़ॉल्ट 0 है, असीमित के बराबर है) या GRANT/CREATE USER/ALTER USER स्टेटमेंट में संसाधन नियंत्रण विकल्पों का उपयोग करें। GRANT स्टेटमेंट एक खाते द्वारा सर्वर से एक साथ कनेक्शन की संख्या को सीमित करने का समर्थन करता है, उदाहरण के लिए:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

MySQL सर्वर पर डिफ़ॉल्ट व्यवस्थापक उपयोगकर्ता नाम "रूट" है। हैकर्स अक्सर इसकी अनुमतियों तक पहुंच हासिल करने का प्रयास करते हैं। इस कार्य को अधिक कठिन बनाने के लिए, "रूट" का नाम बदलकर कुछ और कर दें। MySQL उपयोगकर्ता नाम 32 वर्णों तक लंबा हो सकता है (MySQL 5.7.8 से पहले 16 वर्ण)। जैसा कि नीचे दिखाया गया है, RENAME कथन का उपयोग करके सुपर व्यवस्थापक उपयोगकर्ता के लिए लंबे उपयोगकर्ता नाम का उपयोग करना संभव है:

mysql> RENAME USER root TO new_super_administrator_username;

ClusterControl उपयोगकर्ताओं के लिए एक साइड नोट, ClusterControl को आपके लिए डेटाबेस सर्वर को स्वचालित और प्रबंधित करने के लिए MySQL रूट उपयोगकर्ता और पासवर्ड जानने की आवश्यकता है। डिफ़ॉल्ट रूप से, यह 'रूट' की तलाश करेगा। यदि आप रूट उपयोगकर्ता का नाम बदलकर कुछ और करते हैं, तो cmon_X.cnf (जहाँ X क्लस्टर आईडी है) के अंदर "monitored_mysql_root_user={new_user}" निर्दिष्ट करें और परिवर्तन लागू करने के लिए CMON सेवा को पुनरारंभ करें।

बैकअप नीति

भले ही हैकर्स ने कहा कि फिरौती का भुगतान करने के बाद आपको अपना डेटा वापस मिल जाएगा, आमतौर पर ऐसा नहीं था। बैकअप फ़्रीक्वेंसी बढ़ाने से आपके हटाए गए डेटा को पुनर्स्थापित करने की संभावना बढ़ जाएगी। उदाहरण के लिए, दैनिक वृद्धिशील बैकअप के साथ सप्ताह में एक बार पूर्ण बैकअप के बजाय, आप प्रति घंटा वृद्धिशील बैकअप के साथ दिन में एक बार पूर्ण बैकअप शेड्यूल कर सकते हैं। आप इसे ClusterControl की बैकअप प्रबंधन सुविधा के साथ आसानी से कर सकते हैं, और कुछ गलत होने पर अपने डेटा को पुनर्स्थापित कर सकते हैं।

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

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

अपने वेब/एप्लिकेशन सर्वर की सुरक्षा करें

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

वेब सर्वर से समझौता करने के हजारों तरीके हैं और आप इस उद्देश्य के लिए इनबाउंड पोर्ट 80 या 443 को वास्तव में बंद नहीं कर सकते। आपके वेब सर्वर को HTTP-आधारित इंजेक्शन से सुरक्षित रखने के लिए सुरक्षा की एक और परत की आवश्यकता है। आप Apache ModSecurity, NAXSI (WAF for nginx), WebKnight (IIS के लिए WAF) जैसे वेब एप्लिकेशन फ़ायरवॉल (WAF) का उपयोग कर सकते हैं या बस अपने वेब सर्वर को CloudFlare, Akamai या Amazon CloudFront जैसे सुरक्षित कंटेंट डिलीवरी नेटवर्क (CDN) में चला सकते हैं।

हमेशा अप-टू-डेट रखें

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

उत्पादन के उपयोग के लिए, आपके लिए विक्रेता के भंडार से MySQL/MariaDB संकुल को स्थापित करने की अत्यधिक अनुशंसा की जाती है। डिफ़ॉल्ट ऑपरेटिंग सिस्टम रिपॉजिटरी पर भरोसा न करें, जहां पैकेज आमतौर पर पुराने होते हैं। यदि आप गैलेरा क्लस्टर, या यहां तक ​​​​कि MySQL प्रतिकृति जैसे क्लस्टर वातावरण में चल रहे हैं, तो आपके पास हमेशा न्यूनतम डाउनटाइम के साथ सिस्टम को पैच करने का विकल्प होता है। इसे नियमित बनाएं और जितना हो सके अपग्रेड प्रक्रिया को स्वचालित करने का प्रयास करें।

ClusterControl एक क्लिक के साथ MySQL/MariaDB के लिए लघु संस्करण रोलिंग अपग्रेड (एक समय में एक नोड) का समर्थन करता है। प्रमुख संस्करण अपग्रेड (उदाहरण के लिए, MySQL 5.6 से MySQL 5.7 तक) को आमतौर पर मौजूदा पैकेजों की स्थापना रद्द करने की आवश्यकता होती है और यह स्वचालित करने के लिए एक जोखिम भरा कार्य है। इस तरह के अपग्रेड के लिए सावधानीपूर्वक योजना और परीक्षण आवश्यक है।

निष्कर्ष

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