पासवर्ड और चाबियों के खिलाफ गिटलैब और गिटोलिट की रक्षा करना

हाल ही में, मेरे सर्वर पर gitlab और ssh के लिए पासवर्ड के चयन पर एक हमला एक git रिपॉजिटरी के साथ मेरे सर्वर पर शुरू हुआ। हमलावरों के इरादे स्पष्ट हैं - गिट में संग्रहीत एक मालिकाना आवेदन का स्रोत कोड प्राप्त करने के लिए।

मैं ssh कीज़ को चुनने के प्रयासों को काफी नहीं समझता, क्योंकि RSA कुंजी (यह दशकों लगेंगे) लेने के लिए समस्याग्रस्त है, लेकिन मैंने अभी भी कुछ प्रतिबंध लगाए हैं ताकि लॉग "गड़बड़" न हों।

कौन परवाह करता है कि पासवर्ड अनुमान लगाने से gitolite और gitlab (nginx के लिए काम करता है) की रक्षा कैसे करें - बिल्ली का स्वागत है।

Ssh सुरक्षा।

कई लोग जानते हैं कि अकेले लिनक्स पर sshd कनेक्शन की संख्या को सीमित नहीं कर सकता है। यह हमारे लिए कोई समस्या नहीं थी, हमने उन्हें फ़ायरवॉल स्तर तक सीमित कर दिया।

CentOS के लिए मानक iptables वितरण में एक हैशलीम मॉड्यूल है। हम इसका उपयोग करेंगे। मैंने iptables के लिए निम्नलिखित नियम लिखे:

iptables -N ssh_input iptables -A ssh_input \ -m hashlimit \ --hashlimit 5/m \ --hashlimit-burst 5 \ --hashlimit-mode srcip,dstport \ --hashlimit-name ssh \ --hashlimit-htable-expire 3600000 \ -j ACCEPT iptables -A ssh_input -p tcp -j REJECT --reject-with tcp-reset iptables -A INPUT -m state -m tcp -p tcp --dport 22 --state NEW -j ssh_input 

हमने क्या किया है? पहले हमने ssh_input श्रृंखला जोड़ी। फिर हम एक नियम जोड़ते हैं जो कनेक्शन की संख्या को 5 प्रति मिनट तक सीमित करता है (- अशीलामिट 5 / मी - शशमिलित-फट)। इसमें, हम उन मापदंडों को इंगित करते हैं जिनके द्वारा यह कनेक्शनों को समूहीकृत करने के लायक है (-शालिमित-मोड लिपियों, dstport)। बाद में हम उस नियम को जोड़ते हैं जो पहुंच से इनकार करता है (-j REJECT)। और हम उन स्थितियों के साथ इनपुट करने के लिए एक श्रृंखला जोड़ते हैं जो कनेक्शन नया होना चाहिए और 22 पोर्ट में आना चाहिए।

ये नियम कैसे काम करते हैं? पोर्ट 22 पर नए कनेक्शन ध्वज वाले सभी पैकेट प्रसंस्करण के लिए ssh_input श्रृंखला में भेजे जाते हैं। वहां, इस शर्त के तहत कि किसी दिए गए आईपी से ऐसे कनेक्शनों की संख्या प्रति मिनट 5 से अधिक नहीं है, एक पैकेट पारित किया जाता है (-j ACCEPT)। यदि शर्तों को पूरा नहीं किया जाता है, तो अगले नियम पर जाएं: -j REJECT।

अब हमारे हमलावर साल (दसियों, सैकड़ों साल?) के लिए एक ssh कुंजी उठा सकते हैं। और लॉग का "गड़बड़" कम होगा।

गिटलब संरक्षण

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

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

मूल प्राधिकरण का उपयोगकर्ता नाम और पासवर्ड सभी उपयोगकर्ताओं के लिए सामान्य है और केवल वेब एप्लिकेशन से पासवर्ड के चयन में बाधा के रूप में कार्य करता है। यदि ऐसा है, तो हम निम्नलिखित जांच कर सकते हैं:

 if ($http_authorization != "Basic secretdsddsaadsdsasad=="){ return 403; break; } 

के अलावा अन्य सभी यूआरएल के लिए /। पर / हम मूल प्राधिकरण करते हैं और 1 आईपी के लिए प्रति मिनट 5 प्रयासों की सीमा होती है:

 limit_req_zone $binary_remote_addr zone=one:10m rate=5r/m; ... server { .... location = / { auth_basic "Top secret"; auth_basic_user_file /etc/nginx/conf.d/ssl/.htpasswd; limit_req zone=one burst=5 nodelay; ..... } .... } 

अब आइए कल्पना करें कि हमारा मूल पासवर्ड अभी भी उठाया या चुराया हुआ है। हम एप्लिकेशन लॉगिन फॉर्म की भी रक्षा करते हैं:

 limit_req_zone $binary_remote_addr zone=two:10m rate=5r/m; ... server { ... location = /users/sign_in { if ($http_authorization != "Basic secretdsddsaadsdsasad=="){ //       basic  return 403; break; } limit_req zone=two burst=5 nodelay; .... } .... } 

और अंत में, अन्य पतों के लिए मुख्य स्थान:

 server { ... location / { if ($http_authorization != "Basic secretdsddsaadsdsasad=="){ //       basic  return 403; break; } ... } } 

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