OpenVPN Access Server के लिए Fail2ban फ़िल्टर: real_ip और जेल

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

यह वही रनबुक है जिसका मैं Access Server होस्ट पर पालन करता हूँ: रिकॉर्ड का आकार पुष्टि करें, एक एंकर किया हुआ व्यंजक लिखें, उसे असली लॉग पर परखें, फिर हमले की सतह के अनुसार जेल बाँटें और जाँचें कि ब्लॉक फ़ायरवॉल तक पहुँचता है।

पुष्टि करें कि विफलता रिकॉर्ड मौजूद है

Access Server अपनी संरचित पंक्तियाँ /var/log/openvpnas.log में लिखता है, और क्लाइंट का पता syslog पंक्ति की शुरुआत में नहीं, बल्कि उद्धरण चिह्नों वाले real_ip फ़ील्ड में रहता है। कोई भी पैटर्न लिखने से पहले उस विफल लॉगिन को खोजें जिसके बारे में आप जानते हैं कि वह हुआ था:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

अगर कुछ न दिखे, तो लॉग स्तर अगला संदिग्ध है। Access Server में /usr/local/openvpn_as/etc/as.conf में लॉग-डेटाबेस डीबग स्विच है (DEBUG_LOGDB=1), और इसे बदलने के बाद सेवा को फिर से शुरू करना पड़ता है. उस स्विच को एक नैदानिक सेटिंग मानें जिसे आपका पैटर्न तैयार होने पर फिर नीचे किया जाएगा, स्थायी कॉन्फ़िगरेशन नहीं।

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

real_ip पर एक फ़िल्टर एंकर करें

व्यंजक को सँकरा रखें। IP पता वाली हर पंक्ति का दावा करने वाला फ़िल्टर लोगों को सामान्य डिस्कनेक्ट के लिए ब्लॉक करेगा, और व्यस्त सर्वर पर एकमात्र लक्षण यह है कि उपयोगकर्ता शिकायत करते हैं कि लैपटॉप बंद करने पर उन्हें लॉक कर दिया गया। त्रुटि रिकॉर्ड का दावा करें और उद्धरण चिह्नों वाला पता पकड़ें:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

शुरुआती स्पेस सजावट नहीं है। Access Server अपने रिकॉर्ड को अंदर की ओर धकेलता है, और उस पर एंकर करने से पैटर्न उन पंक्तियों का दावा नहीं कर पाता जो उसी फ़ाइल में असंबंधित सेवाएँ लिखती हैं। यदि आपके रिकॉर्ड की शुरुआत में इसके बजाय टाइमस्टैम्प है, तो उस प्रीफ़िक्स को मिलाएँ, लेकिन ऐसी चीज़ पर एंकर करें जो आपके दावा करने वाले हर रिकॉर्ड में वास्तव में मौजूद हो।

जब आपको प्रति-सतह सटीकता चाहिए, तो उसी पंक्ति में सतह मार्कर (WEB_CLIENT, WEB_ADMIN या VPN) की माँग करके और सँकरा करें। एक शब्द में भिन्न तीन फ़िल्टरों की तुलना में तीन पैटर्न वाला एक फ़िल्टर जाँचना आसान है।

जेल सक्षम करने से पहले व्यंजक परखें

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

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

पहले चरण में सत्यापित विफलताओं से मिलान की संख्या की तुलना करें। शून्य मिलान का अर्थ है कि पैटर्न ग़लत है; जो पंक्तियाँ प्रमाणीकरण विफलता नहीं हैं उन पर मिलान का अर्थ है कि वह बहुत चौड़ा है। missed.txt पढ़ें जब तक आप उन सभी पंक्तियों को समझा न सकें जिनका दावा न करने का आपने चयन किया।

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

जेल को सतह के अनुसार बाँटें, डेमॉन के अनुसार नहीं

एक Access Server कई प्रमाणीकरण सतहें प्रस्तुत करता है: 943/tcp पर क्लाइंट और एडमिन वेब इंटरफ़ेस, और अधिकांश परिनियोजनों में 1194/udp या 443/tcp पर टनल। सभी को ढकने वाला एक ही जेल टनल पर अनुमान के प्रयासों को ऐसा पता ब्लॉक करने देता है जो आपका एडमिन मार्ग भी है, और यह छिपा देता है कि कौन-सी सतह वास्तव में हमले में है। हर सतह को उसका अपना पोर्ट और थ्रेशोल्ड वाला अलग जेल दें:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

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

ब्लॉक, बैकएंड और साइड इफ़ेक्ट जाँचें

पुनः आरंभ के बाद, स्टेटस आउटपुट सबसे तेज़ पुष्टि है कि जेल मौजूद है और गिन रहा है:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

फिर पुष्टि करें कि ब्लॉक उस फ़ायरवॉल तक पहुँचता है जिसे आप वास्तव में चलाते हैं, क्योंकि जिस बैकएंड को कोई लागू नहीं करता उसके लिए बना जेल कुछ भी नहीं बचाता। iptables क्रिया के साथ पते जेल के नाम वाली चेन में दिखते हैं (f2b-openvpnas-tunnel); nftables क्रिया के साथ वे fail2ban की अपनी तालिका के एक सेट में आते हैं। अनुमान लगाने के बजाय वही जाँचें जो आपका होस्ट उपयोग करता है।

दो साइड जाँचें ब्लॉक से भी अधिक महत्वपूर्ण हैं। पहला, पुष्टि करें कि real_ip क्लाइंट का पता है और लोड बैलेंसर या रिवर्स प्रॉक्सी नहीं; प्रॉक्सी के पीछे हर ब्लॉक प्रॉक्सी पर पड़ता है और पूरी सेवा को साथ ले डूबता है। दूसरा, अनब्लॉक प्रक्रिया लिखकर रखें, क्योंकि 02:00 बजे थ्रेशोल्ड पार करने वाला पता आमतौर पर ऑन-कॉल इंजीनियर का होता है: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24।

ट्यूनिंग करते समय सीमा को ध्यान में रखें। Fail2ban एक प्रमाणीकरण सतह पर एक दर सीमक है, प्रवेश नियंत्रण परत नहीं। यह MFA, प्रति-खाता प्रतिबंध या एडमिन इंटरफ़ेस को सार्वजनिक इंटरनेट से बाहर रखने का विकल्प नहीं है, और Access Server की अपनी autoban सेटिंग्स हैं जिन्हें एक ही पोर्ट पर दो दर सीमक ढेर करने से पहले जाँचना ज़रूरी है।