OpenVPN Access Server का लागि Fail2ban फिल्टर: real_ip र jail

तपाईंले समुदाय पोस्टबाट एउटा OpenVPN jail प्रतिलिपि गर्नुभयो, fail2ban पुनः सुरु गर्नुभयो, र कुनै पनि ठेगाना कहिल्यै ब्लक हुँदैन। कारण लगभग सधैं लग ढाँचा हो: Access Server ले स्टक फिल्टरले अपेक्षा गर्ने प्रमाणीकरण-असफलता लाइनहरू लेख्दैन। फिल्टर छुनु अघि रेकर्डहरू साँच्चै छन् कि भनी पुष्टि गर्नुहोस्, किनकि ढाँचाले सेवाले कहिल्यै नलेखेको कुरासँग मिल्न सक्दैन।

Access Server होस्टमा मैले पछ्याउने रनबुक यो हो: रेकर्डको आकार पुष्टि गर्ने, एउटा एङ्कर गरिएको अभिव्यक्ति लेख्ने, वास्तविक लगमा परीक्षण गर्ने, त्यसपछि आक्रमणमा परेको सतह अनुसार jail विभाजन गर्ने र ब्लक फायरवालसम्म पुग्छ भनी जाँच्ने।

असफलताको रेकर्ड छ भनी पुष्टि गर्नुहोस्

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), र यसलाई परिवर्तन गरेपछि सेवा पुनः सुरु गर्नुपर्छ. त्यो स्विचलाई ढाँचा तयार भएपछि फेरि तल झार्नुपर्ने निदान सेटिङको रूपमा लिनुहोस्, स्थायी कन्फिगरेसनको रूपमा होइन।

फाइलमा हुँदा कुन सतहहरूले यसमा लेख्छन् भन्ने नोट गर्नुहोस्। ग्राहक पोर्टल, एडमिन इन्टरफेस र टनेल प्रमाणीकरणका असफलताहरू एउटै फाइलमा फरक मार्करसँग आउँछन्, र त्यो विवरणले पछि jail को लेआउट निर्धारण गर्छ।

real_ip मा एउटा फिल्टर एङ्कर गर्नुहोस्

अभिव्यक्ति साँघुरो राख्नुहोस्। IP ठेगाना भएको जुनसुकै लाइन दाबी गर्ने फिल्टरले मानिसहरूलाई सामान्य डिस्कनेक्टका लागि ब्लक गर्छ, र व्यस्त सर्भरमा ल्यापटप बन्द गरेकोमा लक भएको भन्ने प्रयोगकर्ताको गुनासो मात्र लक्षण हुन्छ। त्रुटिको रेकर्ड दाबी गर्नुहोस् र उद्धरणभित्रको ठेगाना समात्नुहोस्:

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

सुरुको खाली ठाउँ सजावट होइन। Access Server ले आफ्ना रेकर्डहरू भित्र सार्छ, र त्यसमा एङ्कर गर्दा ढाँचाले उही फाइलमा लेख्ने असम्बन्धित सेवाका लाइनहरू पनि दाबी गर्नबाट रोक्छ। यदि तपाईंका रेकर्डको सुरुमा यसको सट्टा समय-छाप छ भने त्यो उपसर्ग मिलाउनुहोस्, तर तपाईंले दाबी गर्न खोजेको हरेक रेकर्डमा साँच्चै उपस्थित कुरामा एङ्कर गर्नुहोस्।

सतह अनुसार शुद्धता चाहिएको बेला उही लाइनमा सतह मार्कर (WEB_CLIENT, WEB_ADMIN वा VPN) मागेर अझ साँघुरो बनाउनुहोस्। एउटा शब्दले फरक पर्ने तीन फिल्टरभन्दा तीन ढाँचा भएको एउटा फिल्टर जाँच्न सजिलो हुन्छ।

jail सक्षम गर्नु अघि अभिव्यक्ति परीक्षण गर्नुहोस्

उत्पादन लगमा नचलाएको फिल्टर कहिल्यै सक्षम नगर्नुहोस्। अभिलेखित परीक्षणले फिल्टर दुई पटक पास गर्छ, एक पटक लोड गर्न र एक पटक लागू गर्न, र छुटेका लाइनहरूको प्रतिवेदन नै पढ्न लायक भाग हो:

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 होइन।

jail लाई सतह अनुसार छुट्याउनुहोस्, डेमन अनुसार होइन

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

# /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 पछाडिका हरेक प्रयोगकर्तालाई दण्ड दिन्छ, र टनेल सतहमा आक्रामक ब्लकले रातभरिमा म्याद सकिएका सङ्ग्रहित प्रमाणहरू भएका वैध ग्राहकहरूलाई विच्छेद गर्छ।

ब्लक, backend र साइड इफेक्ट जाँच्नुहोस्

पुनः सुरु गरेपछि, jail अवस्थित छ र गनिरहेको छ भन्ने सबैभन्दा छिटो पुष्टि स्टेटस आउटपुट हो:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

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

दुई साइड जाँच ब्लकभन्दा पनि महत्त्वपूर्ण छन्। पहिलो, real_ip ग्राहकको ठेगाना हो र लोड ब्यालेन्सर वा रिभर्स प्रोक्सी होइन भनी पुष्टि गर्नुहोस्; प्रोक्सी पछाडि हरेक ब्लक प्रोक्सीमा पर्छ र पूरै सेवा साथै लान्छ। दोस्रो, अनब्लक प्रक्रिया लेखेर राख्नुहोस्, किनकि 02:00 बजे सीमा नाघ्ने ठेगाना सामान्यतया ड्युटीमा रहेको इन्जिनियरको हुन्छ: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24।

ट्युन गर्दा सीमा सम्झनुहोस्। Fail2ban एउटा प्रमाणीकरण सतहमा दर सीमक हो, पहुँच नियन्त्रण तह होइन। यसले MFA, प्रति-खाता प्रतिबन्ध वा एडमिन इन्टरफेस सार्वजनिक इन्टरनेटबाट बाहिर राख्ने कुराको विकल्प हुँदैन, र Access Server का आफ्नै autoban सेटिङहरू छन् जुन एउटै पोर्टमा दुई दर सीमक थुपार्नु अघि जाँच्न लायक छन्।