यह मूल पोलिश लेख का AI-जनित अनुवाद है और इसमें मामूली त्रुटियां हो सकती हैं।

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

प्रश्न: मैं Gitea को जंक अकाउंट्स बनने से कैसे सुरक्षित करूँ? कुछ बॉट्स अंदर आ गए हैं और कचरा फेंक रहे हैं, clearance-center-sofas या top-wooden-pallets जैसे नामों वाली रिपॉजिटरी बनाने की कोशिश कर रहे हैं।

इन्हें Spam Registration Bots कहा जाता है। ये स्क्रिप्ट्स हैं जो ओपन वेब पर लगातार उन Gitea (या GitHub/GitLab) इंस्टेंस को स्कैन करती हैं जिनमें पंजीकरण चालू और खुला होता है। वे फर्जी ई-मेल पते रजिस्टर करते हैं और Google द्वारा इंडेक्स किए जाने वाले कीवर्ड्स से भरी दर्जनों खाली रिपॉजिटरी बनाते हैं। ऐसा करके, वे आपके डोमेन की विश्वसनीयता का फायदा उठाकर एक मुफ़्त SEO बैकलिंक नेटवर्क बनाने की कोशिश करते हैं।

सीधा समाधान: app.ini को संपादित करना

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

अपने होम Linux सर्वर (डॉकर होस्ट) से SSH के माध्यम से कनेक्ट होने के दौरान, मुझे तुरंत संबंधित फ़ाइल मिल गई:

sudo find / -name "app.ini" 2>/dev/null

यह मुझे संलग्न डॉकर वॉल्यूम के भीतर मिली (मेरे मामले में /home/gkucmierz/docker/gitea/gitea/gitea/conf/app.ini)। nano एडिटर का उपयोग करते हुए, मुझे [service] अनुभाग में महत्वपूर्ण रोकथाम जोड़ना आवश्यक था:

[service]
DISABLE_REGISTRATION = true
REQUIRE_SIGNIN_VIEW = true

• DISABLE_REGISTRATION – सार्वजनिक द्वार को बंद कर देता है। अब से, खाते बनाना केवल व्यवस्थापकों के लिए पैनल के माध्यम से संभव है।
• REQUIRE_SIGNIN_VIEW – अत्यधिक जिज्ञासु बाहरी स्क्रैपर्स के विरुद्ध एक वैकल्पिक रक्षा। यह हर यात्रा पर लॉगिन की अनिवार्यता लागू करके Explore पेज के नेटवर्क अनुक्रमण को भी रोकता है।

इन मुहरों को लागू करने के लिए केवल कंटेनर को पुनरारंभ करने की आवश्यकता थी:

docker compose restart gitea

बॉट समाप्ति (Gitea CLI)

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

शेल वातावरण को सक्षम करते हुए (हमारे सेटअप में 'gitea' डॉकर के भीतर आंतरिक 'git' उपयोगकर्ता के रूप में चल रहा है), मैंने एक कमांड जारी किया जिसने सभी कचरों को मिटा दिया और SQL डेटाबेस, रिपॉजिटरी और लिंक की गई कुंजियों को शून्य में बहा दिया:

# कंटेनर शेल में प्रवेश करना (आंतरिक 'git' उपयोगकर्ता के रूप में)
docker exec -it -u git gitea sh

# सत्यापित करना कि सिस्टम में कौन से उपयोगकर्ता और बॉट्स (उनकी IDs और बॉट के नाम) हैं
gitea admin user list

# "metal-bunk-beds" आदि जैसे क्रेडेंशियल वाले कीड़ों का अंतिम, कठिन विलोपन (उनकी सभी रचनाओं को पोंछने के लिए PURGE फ्लैग का उपयोग करना)
sqlite3 /data/gitea/gitea.db "DELETE FROM user WHERE id >= 4; VACUUM;"
# ... जब तक कि सब कुछ एकदम साफ नहीं हो गया

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

युद्धक्षेत्र दस्तावेज़ीकरण (स्क्रीनशॉट्स)

नीचे दस्तावेजी कार्रवाई की पूर्णता है: पहचान, फाइलों का अलगाव, और सीधे Gitea इंटरफेस और सर्वर लॉग से सफाया। फ़ुल-स्क्रीन गैलरी लॉन्च करने के लिए थंबनेल पर क्लिक करें: