सार्वजनिक नेटवर्क पर साइबर हमलों के खिलाफ अपने MySQL और MariaDB डेटाबेस की सुरक्षा कैसे करें

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

यहां कुछ युक्तियां दी गई हैं जो हम अपनी MySQL या MariaDB सुरक्षा को बेहतर बनाने के लिए कर सकते हैं।

अपने डेटाबेस सर्वर को नियमित रूप से स्कैन करें

सर्वर में किसी भी दुर्भावनापूर्ण फ़ाइल से सुरक्षा बहुत महत्वपूर्ण है। किसी भी वायरस, स्पाईवेयर, मालवेयर या रूटकिट को देखने के लिए सर्वर को नियमित रूप से स्कैन करें, खासकर यदि डेटाबेस सर्वर मेल सर्वर, HTTP, FTP, DNS, WebDAV, टेलनेट आदि जैसी अन्य सेवाओं के साथ सह-स्थित है। आमतौर पर, अधिकांश डेटाबेस हैक किए गए मुद्दे एप्लिकेशन टियर से उत्पन्न होते हैं जो सार्वजनिक नेटवर्क का सामना कर रहे हैं। इस प्रकार, सभी फाइलों, विशेष रूप से वेब/एप्लिकेशन फाइलों को स्कैन करना महत्वपूर्ण है क्योंकि वे सर्वर में प्रवेश करने के लिए प्रवेश बिंदुओं में से एक हैं। यदि उनसे समझौता किया जाता है, तो हैकर एप्लिकेशन निर्देशिका में प्रवेश कर सकता है, और एप्लिकेशन फ़ाइलों को पढ़ने की क्षमता रखता है। इनमें संवेदनशील जानकारी हो सकती है, उदाहरण के लिए, डेटाबेस लॉगिन क्रेडेंशियल।

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

0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log

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

सख्त उपयोगकर्ता भूमिकाओं और विशेषाधिकारों का उपयोग करें

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

mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user    | host |
+---------+------+
| myadmin | %    |
| sbtest  | %    |
| user1   | %    |
+---------+------+

उपरोक्त आउटपुट से, उन सभी उपयोगकर्ताओं को सख्त या हटा दें जिनके पास होस्ट कॉलम के तहत केवल '%' मान है। जिन उपयोगकर्ताओं को MySQL सर्वर को दूरस्थ रूप से एक्सेस करने की आवश्यकता होती है, उन्हें SSH टनलिंग विधि का उपयोग करने के लिए लागू किया जा सकता है, जिसके लिए MySQL उपयोगकर्ताओं के लिए दूरस्थ होस्ट कॉन्फ़िगरेशन की आवश्यकता नहीं होती है। अधिकांश MySQL व्यवस्थापन क्लाइंट जैसे कि MySQL वर्कबेंच और HeidiSQL को SSH ट्यूनलिंग के माध्यम से एक MySQL सर्वर से कनेक्ट करने के लिए कॉन्फ़िगर किया जा सकता है, इसलिए MySQL उपयोगकर्ताओं के लिए रिमोट कनेक्शन को पूरी तरह से समाप्त करना संभव है।

साथ ही, सुपर विशेषाधिकार को केवल लोकलहोस्ट के उपयोगकर्ताओं तक सीमित करें, या UNIX सॉकेट फ़ाइल के माध्यम से कनेक्ट करें। गैर-रूट उपयोगकर्ताओं को FILE विशेषाधिकार प्रदान करते समय अधिक सतर्क रहें क्योंकि यह LOAD DATA INFILE और SELECT ... INTO OUTFILE स्टेटमेंट का उपयोग करके सर्वर पर फ़ाइलों को पढ़ने और लिखने की अनुमति देता है। कोई भी उपयोगकर्ता जिसे यह विशेषाधिकार दिया गया है, वह कोई भी फ़ाइल पढ़ या लिख सकता है जिसे MySQL सर्वर पढ़ या लिख सकता है।

डेटाबेस की डिफ़ॉल्ट सेटिंग बदलें

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

डिफ़ॉल्ट MySQL पोर्ट को 3306 के अलावा अन्य में बदलें।
MySQL रूट यूजरनेम का नाम "रूट" के अलावा किसी और में बदलें।
पासवर्ड की समाप्ति लागू करें और सभी उपयोगकर्ताओं के लिए पासवर्ड का जीवनकाल कम करें।
यदि MySQL एप्लिकेशन सर्वर के साथ सह-स्थित है, तो केवल UNIX सॉकेट फ़ाइल के माध्यम से कनेक्शन लागू करें, और सभी IP पतों के लिए पोर्ट 3306 पर सुनना बंद करें।
क्लाइंट-सर्वर एन्क्रिप्शन और सर्वर-सर्वर प्रतिकृति एन्क्रिप्शन लागू करें।

हमने वास्तव में इस ब्लॉग पोस्ट, हाउ टू सिक्योर मायएसक्यूएल/मारियाडीबी सर्वर में विस्तार से कवर किया है।

विलंबित दास को सेटअप करें

एक विलंबित दास केवल एक विशिष्ट दास है, हालांकि दास सर्वर जानबूझकर कम से कम एक निर्दिष्ट समय के बाद मास्टर की तुलना में लेनदेन को निष्पादित करता है, जो MySQL 5.6 से उपलब्ध है। मूल रूप से, मास्टर से प्राप्त एक घटना को कम से कम N . तक निष्पादित नहीं किया जाता है मास्टर पर इसके निष्पादन की तुलना में सेकंड बाद। इसका परिणाम यह होता है कि दास कुछ समय पहले स्वामी की स्थिति को प्रतिबिंबित करेगा।

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

# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

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

बाइनरी लॉगिंग सक्षम करें

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

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

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

फ़्लैशबैक सक्षम करें

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

[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL

निम्न आर्किटेक्चर आरेख दिखाता है कि किसी एक दास पर फ्लैशबैक कैसे कॉन्फ़िगर किया गया है:

फ्लैशबैक ऑपरेशन करने के लिए सबसे पहले आपको तारीख और समय निर्धारित करना होगा जब आप डेटा, या बाइनरी लॉग फ़ाइल और स्थिति को "देखना" चाहते हैं। फिर, उस बिंदु पर डेटा को रोलबैक करने के लिए SQL कथन उत्पन्न करने के लिए mysqlbinlog उपयोगिता के साथ --flashback ध्वज का उपयोग करें। जेनरेट की गई SQL फ़ाइल में, आप देखेंगे कि DELETE ईवेंट INSERTs में परिवर्तित हो जाते हैं और इसके विपरीत, और यह UPDATE ईवेंट के WHERE और SET भागों को भी स्वैप करता है।

निम्न कमांड लाइन को स्लेव2 पर निष्पादित किया जाना चाहिए (binlog_row_image=FULL के साथ कॉन्फ़िगर किया गया):

$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00"  /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sql

फिर, स्लेव2 को प्रतिकृति श्रृंखला से अलग करें क्योंकि हम इसे तोड़ने जा रहे हैं और अपने डेटा को रोलबैक करने के लिए सर्वर का उपयोग करेंगे:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;

अंत में, स्लेव2 पर डेटाबेस शॉप के लिए उत्पन्न SQL फ़ाइल को MariaDB सर्वर में आयात करें:

$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sql

जब उपरोक्त लागू किया जाता है, तो तालिका "उत्पाद" 2020-02-17 01:30:00 की स्थिति में होगी। तकनीकी रूप से, उत्पन्न SQL फ़ाइल को MariaDB और MySQL सर्वर दोनों पर लागू किया जा सकता है। आप मारियाडीबी सर्वर से mysqlbinlog बाइनरी को भी स्थानांतरित कर सकते हैं ताकि आप MySQL सर्वर पर फ्लैशबैक सुविधा का उपयोग कर सकें। हालाँकि, MySQL GTID कार्यान्वयन MariaDB से भिन्न है, इसलिए SQL फ़ाइल को पुनर्स्थापित करने के लिए आपको MySQL GTID को अक्षम करना होगा।

फ्लैशबैक का उपयोग करने के कुछ फायदे हैं कि आपको इस ऑपरेशन को करने के लिए MySQL/MariaDB सर्वर को रोकने की आवश्यकता नहीं है। जब वापस करने के लिए डेटा की मात्रा कम होती है, तो फ्लैशबैक प्रक्रिया पूर्ण बैकअप से डेटा को पुनर्प्राप्त करने की तुलना में बहुत तेज होती है।

सभी डेटाबेस क्वेरी लॉग करें

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

mysql> SET global general_log_file='/tmp/mysql.log'; 
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;

आप सामान्य लॉग आउटपुट को एक टेबल पर भी सेट कर सकते हैं:

mysql> SET global log_output = 'table';

फिर आप प्रश्नों को पुनः प्राप्त करने के लिए mysql.general_log तालिका के विरुद्ध मानक चयन कथन का उपयोग कर सकते हैं। जैसा कि इस ब्लॉग पोस्ट में दिखाया गया है, इस कॉन्फ़िगरेशन के साथ चलते समय थोड़ा अधिक प्रदर्शन प्रभाव की अपेक्षा करें।

अन्यथा, आप बाहरी निगरानी उपकरणों का उपयोग कर सकते हैं जो क्वेरी नमूनाकरण और निगरानी कर सकते हैं ताकि आप सर्वर में आने वाले प्रश्नों को फ़िल्टर और ऑडिट कर सकें। ClusterControl का उपयोग आपके सभी प्रश्नों को एकत्रित और सारांशित करने के लिए किया जा सकता है, जैसा कि निम्नलिखित स्क्रीनशॉट में दिखाया गया है जहां हम DELETE स्ट्रिंग वाली सभी क्वेरी को फ़िल्टर करते हैं:

प्रॉक्सीएसक्यूएल के शीर्ष प्रश्न पृष्ठ के अंतर्गत भी इसी तरह की जानकारी उपलब्ध है (यदि आपका आवेदन ProxySQL के माध्यम से कनेक्ट करना):

इसका उपयोग डेटाबेस सर्वर में हाल के परिवर्तनों को ट्रैक करने के लिए किया जा सकता है और इसका उपयोग ऑडिटिंग उद्देश्यों के लिए भी किया जा सकता है।

निष्कर्ष

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